Em 05-03-2014 18:09, Jean-Philippe Ouellet escreveu: > I'm aware of some issues in this area. > > You probably need to modify boot to default to serial console. The > normal approach, taken by the installer, is to use boot.conf, but of > course that's not readable before the disk is decrypted. This is > assuming you will use serial console to provide the password instead > of regular keyboard. > > If you want to provide the password over the network, I think that's > going to be way more work. pxeboot may be a place to start, but I > don't think you'll like where that leads and it won't be very secure > either. > I think that's silly, then once your box is compromised it could pretend > to be pxebooting and just grab your password, or some passive attacker > on your network could sniff it, or the pxeboot server being compromised > would lead to all your passwords being compromised. > >> Or get a server that supports some sort of kvm/console over IP. > Which likely isn't going to be super secure either. The best remote > access thing I've seen was a sun server which supported ssh, but it was > limited at best. > > The best solution for you really depends on your threat model. > > If you're worried about protecting your data, then you don't really need > full disk encryption, you just need your data partition encrypted. > > If you're worried about protecting your entire system from malicious > people with physical access to your drive, I'd argue that if you need to > defend against that, you're already screwed anyway (they could just > overwrite your bootloader with a malicious one that records your pw, > among a plethora of other potential attacks). > > If by "full disk encryption" you're willing to accept more than your > bootloader being unencrypted, then I'd suggest the old > (pre-bootloader-support) way. You could have your system boot, start > ssh, and notify you (email or whatever) that it needs you to ssh in and > run bioctl(8) yourself, and then go start whatever services you wanted > to actually start at boot. Of course, this could all be nicely automated > with a bit of work. > > This has the advantage of being able to run a good, open, updated sshd > as opposed to whatever "was probably hopefully maybe secure at some > point" embedded sshd shoved into your lights out management > micro-controller with its firmware-limited-to-1024-bit RSA key generated > from very little entropy by a system you can not audit. > > There is certainly something to be said for being able to send your key > out of band, but when "out of band" means a stupid impi controller > hacked into the same network interface anyway, I don't really see the > added security. >
The focus here is to be able to remote unlock it. Manual intervention every time the system reboots is a pain in the ass. Full disk encryption is mostly useful for physical theft of the server. The goal is not to protect the boot process itself. This is another area of work. Now, since OpenBSD is all about security, this remote unlock should be done in the most security wise manner. The security in this context, is network security, not physical security. The analog of linux + initramfs + dropbear that I said is just that, an analog. That do not mean that this is the only way to accomplish it. Having ssh on the boot process would be a byproduct, not the goal. I am looking for suggestions, ideas, because I know this will demand lots of changes, and should be very throughly planned, before implemented. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
