I realize this is beyond the scope of what you're doing here, but it's certainly related. Getting a PXE linux system going is something that's peaked my interest for a while but haven't yet figured out exactly the direction I want to go with it.
My initial thoughts were a basic system that should run easily on any system as sort of a recovery deal. After the meeting though, I've been considering the possible benefits of attempting to do a *real* full disk encryption, and using the PXE boot as a way to initiate that. In my google searches I've found very little information that even includes the words PXE and encryption on the same page (with the exception of the wikipedia article for full disk encryption which mentions: Using a network interchange to recover the key, for instance as part of a PXE boot) Here's a very basic high level overview of what I have in mind (again, I haven't really gotten into any specifics yet and am not sure I will, but the thought is interesting to me). 1) PC boots with the entire hard drive truly encrypted (all of it) 2) PXE boots and gets a basic shell going with a shell going that's being transferred over ssh or some other secure medium 3) User selects boot option, in this case local encrypted volume 4) User inputs password for encrypted volume, upon successful entry the encryption key is securely delivered to the PC over ssh or some secure method 5) key stored temporarily on the pc in memory and boots up from here just like a normal full encryption volume would work You may be wondering why go through the trouble, but actually interestingly enough, I think PXE would solve some of the biggest problems of full disk encryption. For example, the key must be stored on the PC somehow, so it can be retrieved so long as the password is hacked. This makes the power of full disk encryption fully reliant on the entropy of the chosen password or authentication method. Consequently, security on basic things like booting a pc mean the users will be tempted to use easy passwords, will leave in devices with keys on them, etc. While this would not prevent a cold boot attack in any way, it would offer a sane solution to locking down workstations so that the boot options are not there, and the PC will simply always boot from PXE. Once in the PXE interface (whatever you choose to do with it), you could control boot options by permissions and user accounts. Since the key for decrypting the drive would not be physically stored on the drive, having an attacker take the PC/hard drive with intentions of brute forcing would be a complete non-issue. Also, this would make first keylogging the password/key then using it to decrypt the drive not work. So long as the method for transferring the key over the network is sound, I couldn't imagine any other major security risks this would pose (that don't already exist). Any thoughts on this? On Wed, Feb 16, 2011 at 5:55 PM, William L. Thomson Jr. <[email protected]> wrote: > In thinking more about the craziness of the fstab, as displayed last > night as part of my approach to diskless systems, and the local bind > mounts before nfs export on file server. > > I think I am going to move to a scripted approach via a init script. You > can't use variables in fstab, and honestly dealing with that is a pita. > Not just from a maintenance point of view, getting way out of control > size wise with lots of systems. At times during testing or otherwise, > you might want to unbind things, which requires umount. Doing that via > fstab is not easy. You have to do unmount commands manually, which > blows! > > Therefore I think a better approach is to script it, make an init > script, with both start/mount and stop/unmount. Maybe even a config file > in Gentoo's /etc/conf.d/diskless to contain a variable for the amount of > diskless systems. Otherwise can hard code that into the init script, but > probably not the best approach. > > I will provide more information once I get around to completing some how > tos on all this and uploading a copy of the presentation from last > night. But as mentioned last night, its still some what of a work in > progress. Thus delays are par for the course. Not to mention there are > many other approaches, countless links for diskless linux if you Google. > My stuff will just end up as one more. > > -- > William L. Thomson Jr. > Obsidian-Studios, Inc. > http://www.obsidian-studios.com > > > --------------------------------------------------------------------- > Archive http://marc.info/?l=jaxlug-list&r=1&w=2 > RSS Feed http://www.mail-archive.com/[email protected]/maillist.xml > Unsubscribe [email protected] > > --------------------------------------------------------------------- Archive http://marc.info/?l=jaxlug-list&r=1&w=2 RSS Feed http://www.mail-archive.com/[email protected]/maillist.xml Unsubscribe [email protected]
