This is the very thing that makes encryption+law so interesting.
In the "real world" the safe in the wall can be opened by brute force. A diamond tipped circular saw / giant freakin laser beam would make short work of the physical safe.
In the "math world", intractable is intractable. You can't reversse a %mod operation, and factoring is Hard.
So what are the implications?
Scenarios: Genuinely innocent individual downloads PGP after reading interesting internet article about encryption on the internet. Individual encrypts mundane files "just to play" with some software, and forgets the key/passphrase Individual's computer gets confiscated by the police because of an RIAA complaint (or terrorism investigations, whatever)
Genuinely guilty evil doer downloads PGP after reading interesting internet article about encryption on the internet. Evil doer encrypts genuinely incriminating files for the purposes of not letting the powers that be see the evidence. Individual's computer gets confiscated by the police because of an RIAA complaint (or terrorism investigations, whatever)
What now?
The safe analogy and any self incrimination vs plausible deniability arguments become blurred because of circumstance. The safe cannot be opened. Circumstance is now in play... 10 gigs of encrypted files with time stamps relevant to the accused infraction would indicate "something to hide"... but you can never be sure.
Are there any plans to enhance the authentication capabilities of the server to match what's available with Postgres/Oracle? One thing I've always wished for is the ability to authenticate user/service access to databases and tables via other backends (pam_krb5, SASL, ldap, etc). This ability (imho) would result in wider adoption in certain IT shops where compliance officers and checklist junkies would opt to instead shell out for Oracle Advanced Security or something similar.
Gentoo is great. Gentoo is wonderful. *IF* you're only administrating a small handful of servers.
When you have to look out for a few HUNDRED machines at a time, you **reaaaally** start to appreciate things like calendar based release cycles, binary packages, uniformity, hardware compatibility lists, repository mirroring, etc.
Gentoo is far too schizophrenic to be a reliable environment for n servers, especially in a "real" scenario.
Academically, Gentoo is a wonderful system.... but its one of those things that works "great on paper" but sucks a lot of ass in Real Life. Trust me, you have better things to do than worry about than whether or not upgrading one package for a minor security fix will drag along your system libs and userland utils with it. If this is the sort of thing you concern yourself with on a day to day basis, you're doing something WRONG.
Large environment management is a constant battle with entropy. Hard drives die, switches fail, nics go bad, boards burn out, storage space fills up, and all this has to be dealt with. Using predictable, understandable, documented, tested and supported systems creates One Less Thing to worry about.
An entire IT staff should not have to be briefed on a daily basis about what the Gentoo Administrator decided to include in his(her?) build flags./rant// I hate computers.
Simple. PSI (unlike gaim) supports protocol transports. You can sign into your AOL, Yahoo, etc accounts through your jabber server.
This allows you to firewall off all the major chat services from their native clients and still allow your employees to talk on their personal IM accounts to the outside world while logging all the conversations.
Obtaining a fake ID is cake anyway. The problem is in the authentication chain:
Scenario: your house burns down and you lose your ID, passport, social security card, etc. What is the protocol for reobtaining these documents?
step 1) Go to your place of births city records department step 2) Provide them your name, your birth county, your mothers full maiden name, and your birth date. step 3) Shell out 10-20 dollars. step 4) Hold out hand step 5) Receive copy of birth certificate.
step 6) go across the street and present birth certificate and obtain social security card.
step 7) Use these two documents to obtain drivers license.
step 7b) If you live in a state where they keep your photo in a database and compare it with your acual face for replacements, simply go to another state and apply for a license there.
step 8) Use these documents to obtain new National ID card.
Acually, SLES9 ships with an LDAP server, and the regular Suse ftp distro/suse pro/ and I would assume NLD9/10 will authenticate against it by default, with TLS.
The other uses of Active Directory, such as software management, are fufilled by ZenWorks.
What *I* would love to see Novell do is some work on NFS4/kerb to complete the package.
Depending on the size of your company and the needs of your users, you might want to look into the Linux Terminal Server project
The idea is: Set up one windows machine with Terminal Server enabled. Network book diskless workstations (aka super cheap, easily replaceable, no maintenance.) and have them book a small linux configuration that has them log in, and then immediately brings up an rdestop connection to your terminal server.
Users can then log into the One Windows Machine and do what they need to do.
This cuts down your administration time (cost) to only having to admin one machine, and all of the sudden your backups are centralized as well.
For Linux users, you can either have then netboot their entire OS into a ramdisk and mount their home directories over nfs, or just have them open up a remote X login for a true linux terminal server.
We mainly use redhat/fedora here, and I do have to say that all of the things that I've "fought" with redhat to get working properly "just work" right out of the box with SUSE.
Scenario:
I wanted to unify all logins across linux/windows machines on my companies user network.
We were running an NT4 domain controller and using local passwd authentication for all linux servers/workstations.
The natural solution to this was to set up an ldap server, have all the linux machines authenticate off it, and then replace the NT4 domain that would authenticate off the same ldap database. While we're at it, we thought we should enable fine grained access control lists for local filesystems, the samba interface, oh, and they should work over NFS as well. (acl.bestbits.at)
After about 2 months with redhat battling compilation issues, config issues, library issues, and other issues, rpm issues, and a bottle of aprin. I finally managed to get an openldap server up and running, with samba3 authenticating against it in a test environment.
Another month later, I got the ACLs working.
I about kicked myself in the head when, upon evaluating SLES9, I found that during installation it acually gave me an option to use ldap as the main authentication mechanism. Also, it has a built in, YAST controlled CA magement system, replacing all the scripts that I had written to handle ssl certificates.
I recreated my entire test environent in under an hour using SLES9.
On the client end, Suse 9.2 "just works" in every imaginable way. The only things I had to install myself for workstations were enigmail and slocate.
To this day, I still have a few redhat machines that blow up when trying to use ldap/ssl, but everything suse has worked perfectly the first time.
Naturally, it comes with a bunch of databases, a kickass update mechanism (yast), an automated setup tool (autoyast), and now has very nice support from the nice folks over at novell.
On the flip side, I would probably still use redhat for "mission critical" things, as redhats QA proccess is insane. You wont get the nice new extras, but thats because the bleeding edge tends to be unstable.
Also, another thing that needs to be thought about is "googleability." Googleability is a measure of how quickly you can find your problem, then an answer to it, using google. Redhat has much higher googleability that Suse, or any other linux distro for that matter (except perhaps debian), but to be fair, Suse (from my brief experience) tends to have less problems.
In conclusion: Suse for your internal network/workstations/etc. Redhat for your webservers and other things that should have obscene uptimes.
We should be able to just figure out exaclty how improbable it would be for us to build this thing, feed it into a computer, and drink a nice hot cup of tea. poof!
Slashdot Mirror
This is the very thing that makes encryption+law so interesting.
In the "real world" the safe in the wall can be opened by brute force.
A diamond tipped circular saw / giant freakin laser beam would make short work of the physical safe.
In the "math world", intractable is intractable. You can't reversse a %mod operation, and factoring is Hard.
So what are the implications?
Scenarios:
Genuinely innocent individual downloads PGP after reading interesting internet article about encryption on the internet.
Individual encrypts mundane files "just to play" with some software, and forgets the key/passphrase
Individual's computer gets confiscated by the police because of an RIAA complaint (or terrorism investigations, whatever)
Genuinely guilty evil doer downloads PGP after reading interesting internet article about encryption on the internet.
Evil doer encrypts genuinely incriminating files for the purposes of not letting the powers that be see the evidence.
Individual's computer gets confiscated by the police because of an RIAA complaint (or terrorism investigations, whatever)
What now?
The safe analogy and any self incrimination vs plausible deniability arguments become blurred because of circumstance. The safe cannot be opened.
Circumstance is now in play...
10 gigs of encrypted files with time stamps relevant to the accused infraction would indicate "something to hide"... but you can never be sure.
This should be interesting to watch play out.
-s
Are there any plans to enhance the authentication capabilities of the server to match what's available with Postgres/Oracle?
One thing I've always wished for is the ability to authenticate user/service access to databases and tables via other backends (pam_krb5, SASL, ldap, etc). This ability (imho) would result in wider adoption in certain IT shops where compliance officers and checklist junkies would opt to instead shell out for Oracle Advanced Security or something similar.
-s
Gentoo is great.
Gentoo is wonderful.
*IF* you're only administrating a small handful of servers.
When you have to look out for a few HUNDRED machines at a time, you **reaaaally** start to appreciate things like calendar based release cycles, binary packages, uniformity, hardware compatibility lists, repository mirroring, etc.
Gentoo is far too schizophrenic to be a reliable environment for n servers, especially in a "real" scenario.
Academically, Gentoo is a wonderful system.... but its one of those things that works "great on paper" but sucks a lot of ass in Real Life. Trust me, you have better things to do than worry about than whether or not upgrading one package for a minor security fix will drag along your system libs and userland utils with it. If this is the sort of thing you concern yourself with on a day to day basis, you're doing something WRONG.
Large environment management is a constant battle with entropy.
Hard drives die, switches fail, nics go bad, boards burn out, storage space fills up, and all this has to be dealt with. Using predictable, understandable, documented, tested and supported systems creates One Less Thing to worry about.
An entire IT staff should not have to be briefed on a daily basis about what the Gentoo Administrator decided to include in his(her?) build flags.
-s
Simple. PSI (unlike gaim) supports protocol transports.
You can sign into your AOL, Yahoo, etc accounts through your jabber server.
This allows you to firewall off all the major chat services from their native clients and still allow your employees to talk on their personal IM accounts to the outside world while logging all the conversations.
Obtaining a fake ID is cake anyway.
The problem is in the authentication chain:
Scenario: your house burns down and you lose your ID, passport, social security card, etc. What is the protocol for reobtaining these documents?
step 1) Go to your place of births city records department
step 2) Provide them your name, your birth county, your mothers full maiden name, and your birth date.
step 3) Shell out 10-20 dollars.
step 4) Hold out hand
step 5) Receive copy of birth certificate.
step 6) go across the street and present birth certificate and obtain social security card.
step 7) Use these two documents to obtain drivers license.
step 7b) If you live in a state where they keep your photo in a database and compare it with your acual face for replacements, simply go to another state and apply for a license there.
step 8) Use these documents to obtain new National ID card.
-s
Acually, SLES9 ships with an LDAP server, and the regular Suse ftp distro/suse pro/ and I would assume NLD9/10 will authenticate against it by default, with TLS.
The other uses of Active Directory, such as software management, are fufilled by ZenWorks.
What *I* would love to see Novell do is some work on NFS4/kerb to complete the package.
One thing at a time!
-s
Depending on the size of your company and the needs of your users, you might want to look into the Linux Terminal Server project
The idea is:
Set up one windows machine with Terminal Server enabled. Network book diskless workstations (aka super cheap, easily replaceable, no maintenance.) and have them book a small linux configuration that has them log in, and then immediately brings up an rdestop connection to your terminal server.
Users can then log into the One Windows Machine and do what they need to do.
This cuts down your administration time (cost) to only having to admin one machine, and all of the sudden your backups are centralized as well.
For Linux users, you can either have then netboot their entire OS into a ramdisk and mount their home directories over nfs, or just have them open up a remote X login for a true linux terminal server.
Something to look into...
-s
Im going to have to run with SUSE here.
We mainly use redhat/fedora here, and I do have to say that all of the things that I've "fought" with redhat to get working properly "just work" right out of the box with SUSE.
Scenario:
I wanted to unify all logins across linux/windows machines on my companies user network.
We were running an NT4 domain controller and using local passwd authentication for all linux servers/workstations.
The natural solution to this was to set up an ldap server, have all the linux machines authenticate off it, and then replace the NT4 domain that would authenticate off the same ldap database. While we're at it, we thought we should enable fine grained access control lists for local filesystems, the samba interface, oh, and they should work over NFS as well. (acl.bestbits.at)
After about 2 months with redhat battling compilation issues, config issues, library issues, and other issues, rpm issues, and a bottle of aprin. I finally managed to get an openldap server up and running, with samba3 authenticating against it in a test environment.
Another month later, I got the ACLs working.
I about kicked myself in the head when, upon evaluating SLES9, I found that during installation it acually gave me an option to use ldap as the main authentication mechanism. Also, it has a built in, YAST controlled CA magement system, replacing all the scripts that I had written to handle ssl certificates.
I recreated my entire test environent in under an hour using SLES9.
On the client end, Suse 9.2 "just works" in every imaginable way. The only things I had to install myself for workstations were enigmail and slocate.
To this day, I still have a few redhat machines that blow up when trying to use ldap/ssl, but everything suse has worked perfectly the first time.
Naturally, it comes with a bunch of databases, a kickass update mechanism (yast), an automated setup tool (autoyast), and now has very nice support from the nice folks over at novell.
On the flip side, I would probably still use redhat for "mission critical" things, as redhats QA proccess is insane. You wont get the nice new extras, but thats because the bleeding edge tends to be unstable.
Also, another thing that needs to be thought about is "googleability." Googleability is a measure of how quickly you can find your problem, then an answer to it, using google. Redhat has much higher googleability that Suse, or any other linux distro for that matter (except perhaps debian), but to be fair, Suse (from my brief experience) tends to have less problems.
In conclusion: Suse for your internal network/workstations/etc. Redhat for your webservers and other things that should have obscene uptimes.
-s
We should be able to just figure out exaclty how improbable it would be for us to build this thing, feed it into a computer, and drink a nice hot cup of tea. poof!