Re: Boot network for remote unlock of fde
Em 05-03-2014 23:17, Theo de Raadt escreveu: >> But I believe, not have looked much at the code yet, that the kexec() >> approach would be simpler than implementing the pivot_root(). > Well, certainly less issues to deal with in C code. Instead you'll be > running up against debugging things relating to that file called > locore.S ... Yes, I was looking at this file a few moments before you e-mail arrived. Seems some pretty scary asm stuff. Nevertheless, I'm still willing to take a look at it. So everybody agrees that the kexec() approach is the best one? Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: Boot network for remote unlock of fde
> But I believe, not have looked much at the code yet, that the kexec() > approach would be simpler than implementing the pivot_root(). Well, certainly less issues to deal with in C code. Instead you'll be running up against debugging things relating to that file called locore.S ...
Re: Boot network for remote unlock of fde
Em 05-03-2014 23:01, Ted Unangst escreveu: > If we're going to discuss things that would be useful, I have for > quite some time wanted a kexec() syscall that loads a new kernel and > reboots into it. I think that would be helpful for a variety of tasks, > not least of which is avoiding the four minute BIOS countdown sequence > on overengineered servers. > > As for FDE, you'd initially boot to a small, normal OpenBSD > installation. Like an initramfs, but not all scrunched up. You login > via ssh and run "kexec /bsd sr0a:password" or something, > which tells the system to reboot with that kernel, except using softraid > as the root partition. > Now we're talking. I thought of this also, didn't looked at the complexity of it yet. Another task where it would be useful, is in overwriting the RAM with /dev/zero or /dev/random. This approach is used on TAILS live cd to wipe the RAM after use. But I believe, not have looked much at the code yet, that the kexec() approach would be simpler than implementing the pivot_root(). Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: Boot network for remote unlock of fde
On Wed, Mar 05, 2014 at 22:28, Giancarlo Razzolini wrote: > Rather than that, what about contribute with ideas for this. I believe > that it's not only FDE unlocking that would benefit of early network. As > I mentioned before, the possibility of redirecting the console to the > ssh session is one of them. I believe that there are others. Come on > guys, I'm not asking for implementation, just want some pointers and > ideas. I know it would be a very hard task, but I would like the challenge. If we're going to discuss things that would be useful, I have for quite some time wanted a kexec() syscall that loads a new kernel and reboots into it. I think that would be helpful for a variety of tasks, not least of which is avoiding the four minute BIOS countdown sequence on overengineered servers. As for FDE, you'd initially boot to a small, normal OpenBSD installation. Like an initramfs, but not all scrunched up. You login via ssh and run "kexec /bsd sr0a:password" or something, which tells the system to reboot with that kernel, except using softraid as the root partition.
Re: Boot network for remote unlock of fde
Em 05-03-2014 19:03, Chris Cappuccio escreveu: > > Personally I think this sort-of soft-IPMI is a pretty cool idea and I found > Matthieu's reply enlightening as well. > > Apparently Linux has made some progress beyond pivot_root and there are > some interesting ideas there. (Note that we have a functioning tmpfs.) > > http://www.spinics.net/lists/util-linux-ng/msg08794.html > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/ramfs-rootfs-initramfs.txt > > Evolving the kernel ramdisk to extract archive to a tmpfs might be the right > thing to do if the BSD tmpfs has the same advantages (doesn't run the > "backing store" back through the buffer cache etc.) Chris, The first answer that is trying to give some ideas, rather than just criticizing security. I'm aware of all the shortcomings of this solution. I had to hack some time with linux's initramfs to get some sense of security. I even managed to have pppd embedded on it so I can unlock my server over the internet, not just lan. I have it even to run some script that set's it's ip address on my dns server that has it's SSHFP record, so I won't be victim to impersonating attacks. It's working quite well, I must say. Physical access means game over, even more with the solution pointed by you guys, of moving things and creating symlinks. It opens up more attack vectors. Telling me to have another machine to redirect the console to, booting with a pendrive, and every other ideas that rely on external things, is not necessary. I'm aware of those possibilities. Rather than that, what about contribute with ideas for this. I believe that it's not only FDE unlocking that would benefit of early network. As I mentioned before, the possibility of redirecting the console to the ssh session is one of them. I believe that there are others. Come on guys, I'm not asking for implementation, just want some pointers and ideas. I know it would be a very hard task, but I would like the challenge. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: Boot network for remote unlock of fde
previously on this list Kevin Chadwick contributed: > Though I can understand the FDE approach for Linux due to it's rather > and pointlessly (IMO) complex boot. Obviously not all using the linux kernel like buildroot for embedded which can be literally six lines of shell but probably every desktop distro. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___
Re: Boot network for remote unlock of fde
previously on this list Giancarlo Razzolini contributed: > I prefer to have /etc and everything else > encrypted. If not, I would have to move lots of configuration files to > the encrypted partition, not to mention that it would very error prone. You can always use symlinks or mount encrypted partitions into say /etc/ssl. I believe the absolute OpenBSD original book mentioned you couldn't have /etc on it's own partition and I guess it must be on root for boot of /etc/rc but I would also guess you could mount over the top before starting sensitive data handling services. You would just need to keep them in sync when upgrading the system and thankfully OpenBSD's startup is rather neat and can be handled with comparatively little trouble Though I can understand the FDE approach for Linux due to it's rather and pointlessly (IMO) complex boot. It seems to me you are going to a lot of effort to achieve little but a slower system with less entropy and aiding crypt-analysis a little due to predictable data when all you really need is a bit of scripting or consideration of how you can most conveniently and best protect what you need to. Encrypting logs is no chicken and egg problem and very straight forward. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___
Re: Boot network for remote unlock of fde
On 2014/03/06 09:15, Damien Miller wrote: > On Wed, 5 Mar 2014, Stuart Henderson wrote: > > > What are you trying to protect against? > > > > If somebody has physical access, they can presumably replace the > > kernel/initramfs with a trojanned version ... > > It protects against stolen machines, but not active attacks. > > Our cryptoraid doesn't protect against active attacks either - the > attacker can replace the bootloader with something that phishes your > password. The closest we could get to fixing that would be to use the > TPM on some x86 systems, but there are ways around that too... > > -d > If that's the use case, then a custom rc script or ramdisk kernel that lets you ssh in, unlock most of the disk, and start other daemons might be enough.. If it's desirable to protect /etc, the majority of files in there could be copied over to ramdisk after mounting (or a partition on the protected disk could be mounted over the minimal /etc)..
Re: Boot network for remote unlock of fde
On Wed, 5 Mar 2014, Stuart Henderson wrote: > What are you trying to protect against? > > If somebody has physical access, they can presumably replace the > kernel/initramfs with a trojanned version ... It protects against stolen machines, but not active attacks. Our cryptoraid doesn't protect against active attacks either - the attacker can replace the bootloader with something that phishes your password. The closest we could get to fixing that would be to use the TPM on some x86 systems, but there are ways around that too... -d
Re: Boot network for remote unlock of fde
Giancarlo Razzolini [grazzol...@gmail.com] wrote: > > One byproduct of such design would be the possibility of redirecting the > console to the ssh connection. I know this is deranging from the initial > idea, but make perfect sense. Anyway, I noted your concerns on this. > Now, anyone have any design idea for implementing this? > Personally I think this sort-of soft-IPMI is a pretty cool idea and I found Matthieu's reply enlightening as well. Apparently Linux has made some progress beyond pivot_root and there are some interesting ideas there. (Note that we have a functioning tmpfs.) http://www.spinics.net/lists/util-linux-ng/msg08794.html https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/ramfs-rootfs-initramfs.txt Evolving the kernel ramdisk to extract archive to a tmpfs might be the right thing to do if the BSD tmpfs has the same advantages (doesn't run the "backing store" back through the buffer cache etc.)
Re: Boot network for remote unlock of fde
On Wed, Mar 05, 2014 at 06:36:55PM -0300, Giancarlo Razzolini wrote: | One byproduct of such design would be the possibility of redirecting the | console to the ssh connection. I know this is deranging from the initial | idea, but make perfect sense. Anyway, I noted your concerns on this. | Now, anyone have any design idea for implementing this? Your SSH key will always be readable. Either you have a readable SSH host key in the initramfs or the one on disk is readable. With your ssh host key compromised, your disk encryption means nothing. I have one machine in a datacenter with FDE. Well, almost Full: I added a very small sd0a partition with an /etc/boot.conf that sets console output to the serial port. Then I have secure access to the console via another machine where I have ssh access. Of course, if that other machine ever gets compromised, my FDE password is equally compromised. There's one other downside to the small sd0a as of somewhere between 5.4 and 5.5: I now have an /etc/random.seed there too that I need to remember to update after a reboot (I've got an @reboot cron to remind me though). Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: Boot network for remote unlock of fde
Em 05-03-2014 18:22, Ted Unangst escreveu: > On Wed, Mar 05, 2014 at 17:48, Giancarlo Razzolini wrote: >> Thank you for your reply. I am tending for the generic solution for >> unlocking it via network. Not using console nor any hardware assist. On >> linux, using initramfs + busybox + dropbear + some other hacks, it works >> quite well and secure, since you unlock it through ssh. > That sounds like something less than full disk encryption. Yes, the boot section must be unencrypted unless you use an external device (ie. pendrive, usb disk) to boot it. But this is not generic and not very useful. > I'd just do what you had to do before boot supported encryption. Put > /home or wherever your data is in softraid, mark it 0 0 in fstab, and > then after you boot, login and bioctl/mount it manually. > > I think FDE is useful on a notebook/desktop where you may reboot > somewhat frequently, but always have console access. It's easier and > it spares me from typing my password half way through the boot sequence. > > On a server, this is only making things harder for no additional > security. You don't know when initramfs sshd actually starts, so you're > going to what, ping it until you get an answer? Protect the things that > are important, leave the rest alone. I put a lot of intelligence on the configuration of the services that the machine run, and I prefer to have /etc and everything else encrypted. If not, I would have to move lots of configuration files to the encrypted partition, not to mention that it would very error prone. Servers generally have more sensitive data, so full disk encryption make perfectly sense. I don't want one of my servers to be physically stolen and to worry if I didn't leaved anything behind laying in the unencrypted root partition. > > The only advice would be to start fewer daemons in rc. Just start > sshd. Then start mail or web server or whatever later, assuming you > want their data encrypted. This is a five line shell script that > means you're still running OpenBSD, not bizarro almost but not really > OpenBSD. > > I want logs encrypted. They contain lots of information that could be used on an attack. Just to mention user names, if I leave sshd unencrypted. One byproduct of such design would be the possibility of redirecting the console to the ssh connection. I know this is deranging from the initial idea, but make perfect sense. Anyway, I noted your concerns on this. Now, anyone have any design idea for implementing this? Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: Boot network for remote unlock of fde
On Wed, Mar 05, 2014 at 17:48, Giancarlo Razzolini wrote: > Thank you for your reply. I am tending for the generic solution for > unlocking it via network. Not using console nor any hardware assist. On > linux, using initramfs + busybox + dropbear + some other hacks, it works > quite well and secure, since you unlock it through ssh. That sounds like something less than full disk encryption. I'd just do what you had to do before boot supported encryption. Put /home or wherever your data is in softraid, mark it 0 0 in fstab, and then after you boot, login and bioctl/mount it manually. I think FDE is useful on a notebook/desktop where you may reboot somewhat frequently, but always have console access. It's easier and it spares me from typing my password half way through the boot sequence. On a server, this is only making things harder for no additional security. You don't know when initramfs sshd actually starts, so you're going to what, ping it until you get an answer? Protect the things that are important, leave the rest alone. The only advice would be to start fewer daemons in rc. Just start sshd. Then start mail or web server or whatever later, assuming you want their data encrypted. This is a five line shell script that means you're still running OpenBSD, not bizarro almost but not really OpenBSD.
Re: Boot network for remote unlock of fde
On Wed, Mar 05, 2014 at 06:11:35PM -0300, Giancarlo Razzolini wrote: > > > I'm not trying to protect anything. Physical access almost always > means game over. There could be some work on the area of trusted > booting, using TPM chips, but this is another beast entirely. > > I'm trying to be able to remote unlock my full disk encrypted > OpenBSD installation in a way that the keystrokes can't be intercepted > in the wire. There is already a protocol for this, which is ssh. The > trick is to have it working in the boot process. you could try to reproduce the Linux initramfs configuration with a bsd.rd (the installer) like setup to launch an ssh server unlock you real root. But OpenBSD is missing the pivot_root system call, so you'll need to implement it. Other tricks (like just chrooting into the real root fs) will produce more or less frankenstein systems that wont reboot cleanly or may exhibit other unexpected behaviours. -- Matthieu Herrb
Re: Boot network for remote unlock of fde
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
Re: Boot network for remote unlock of fde
Em 05-03-2014 18:05, Stuart Henderson escreveu: > On 2014/03/05 17:48, Giancarlo Razzolini wrote: >> Em 05-03-2014 17:30, Ted Unangst escreveu: >>> On Wed, Mar 05, 2014 at 16:15, Giancarlo Razzolini wrote: Hi, I have one linux server that has full disk encryption, and I use it's initramfs with dropbear to be able to remote unlock the encrypted root partition. From what I read from the OpenBSD documentation, this is not possible now. I want some guidance for what areas of code I would need to modify, to accomplish the same. I know it would involve lots of hacking with boot(8), with the kernel itself, and perhaps more. Also, I want to know how hard you guys think it would be. >>> 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. >>> >>> Or get a server that supports some sort of kvm/console over IP. >> Ted, >> >> Thank you for your reply. I am tending for the generic solution for >> unlocking it via network. Not using console nor any hardware assist. On >> linux, using initramfs + busybox + dropbear + some other hacks, it works >> quite well and secure, since you unlock it through ssh. >> I took a look at pxeboot, but I don't think it will work. I know it >> is a chicken-egg problem, but I want to take a shot at it. Just would >> like some guidance, where to start. I know that maybe it would need some >> approach in the lines of initramfs, but I would avoid it as much as I >> can, if possible. I think a unencrypted partition/disklabel with >> boot.conf and the kernel, plus some hack with boot itself to initialize >> the network device, and configure it's ip address would be more >> interesting. Or even just boot.conf on the partition. This would require >> that boot(8) would do most of the work, even a small sshd >> implementation. Any ideas? >> >> Cheers, >> >> -- >> Giancarlo Razzolini >> GPG: 4096R/77B981BC >> > What are you trying to protect against? > > If somebody has physical access, they can presumably replace the > kernel/initramfs > with a trojanned version ... > > I'm not trying to protect anything. Physical access almost always means game over. There could be some work on the area of trusted booting, using TPM chips, but this is another beast entirely. I'm trying to be able to remote unlock my full disk encrypted OpenBSD installation in a way that the keystrokes can't be intercepted in the wire. There is already a protocol for this, which is ssh. The trick is to have it working in the boot process. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: Boot network for remote unlock of fde
On 3/5/14 3:30 PM, Ted Unangst wrote: > On Wed, Mar 05, 2014 at 16:15, Giancarlo Razzolini wrote: >> Hi, >> >> I have one linux server that has full disk encryption, and I use >> it's initramfs with dropbear to be able to remote unlock the encrypted >> root partition. >> >> From what I read from the OpenBSD documentation, this is not >> possible now. I want some guidance for what areas of code I would need >> to modify, to accomplish the same. I know it would involve lots of >> hacking with boot(8), with the kernel itself, and perhaps more. Also, I >> want to know how hard you guys think it would be. > > 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.
Re: Boot network for remote unlock of fde
On 2014/03/05 17:48, Giancarlo Razzolini wrote: > Em 05-03-2014 17:30, Ted Unangst escreveu: > > On Wed, Mar 05, 2014 at 16:15, Giancarlo Razzolini wrote: > >> Hi, > >> > >> I have one linux server that has full disk encryption, and I use > >> it's initramfs with dropbear to be able to remote unlock the encrypted > >> root partition. > >> > >> From what I read from the OpenBSD documentation, this is not > >> possible now. I want some guidance for what areas of code I would need > >> to modify, to accomplish the same. I know it would involve lots of > >> hacking with boot(8), with the kernel itself, and perhaps more. Also, I > >> want to know how hard you guys think it would be. > > 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. > > > > Or get a server that supports some sort of kvm/console over IP. > Ted, > > Thank you for your reply. I am tending for the generic solution for > unlocking it via network. Not using console nor any hardware assist. On > linux, using initramfs + busybox + dropbear + some other hacks, it works > quite well and secure, since you unlock it through ssh. > I took a look at pxeboot, but I don't think it will work. I know it > is a chicken-egg problem, but I want to take a shot at it. Just would > like some guidance, where to start. I know that maybe it would need some > approach in the lines of initramfs, but I would avoid it as much as I > can, if possible. I think a unencrypted partition/disklabel with > boot.conf and the kernel, plus some hack with boot itself to initialize > the network device, and configure it's ip address would be more > interesting. Or even just boot.conf on the partition. This would require > that boot(8) would do most of the work, even a small sshd > implementation. Any ideas? > > Cheers, > > -- > Giancarlo Razzolini > GPG: 4096R/77B981BC > What are you trying to protect against? If somebody has physical access, they can presumably replace the kernel/initramfs with a trojanned version ...
Re: Boot network for remote unlock of fde
Em 05-03-2014 17:30, Ted Unangst escreveu: > On Wed, Mar 05, 2014 at 16:15, Giancarlo Razzolini wrote: >> Hi, >> >> I have one linux server that has full disk encryption, and I use >> it's initramfs with dropbear to be able to remote unlock the encrypted >> root partition. >> >> From what I read from the OpenBSD documentation, this is not >> possible now. I want some guidance for what areas of code I would need >> to modify, to accomplish the same. I know it would involve lots of >> hacking with boot(8), with the kernel itself, and perhaps more. Also, I >> want to know how hard you guys think it would be. > 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. > > Or get a server that supports some sort of kvm/console over IP. Ted, Thank you for your reply. I am tending for the generic solution for unlocking it via network. Not using console nor any hardware assist. On linux, using initramfs + busybox + dropbear + some other hacks, it works quite well and secure, since you unlock it through ssh. I took a look at pxeboot, but I don't think it will work. I know it is a chicken-egg problem, but I want to take a shot at it. Just would like some guidance, where to start. I know that maybe it would need some approach in the lines of initramfs, but I would avoid it as much as I can, if possible. I think a unencrypted partition/disklabel with boot.conf and the kernel, plus some hack with boot itself to initialize the network device, and configure it's ip address would be more interesting. Or even just boot.conf on the partition. This would require that boot(8) would do most of the work, even a small sshd implementation. Any ideas? Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: Boot network for remote unlock of fde
On Wed, Mar 05, 2014 at 16:15, Giancarlo Razzolini wrote: > Hi, > > I have one linux server that has full disk encryption, and I use > it's initramfs with dropbear to be able to remote unlock the encrypted > root partition. > > From what I read from the OpenBSD documentation, this is not > possible now. I want some guidance for what areas of code I would need > to modify, to accomplish the same. I know it would involve lots of > hacking with boot(8), with the kernel itself, and perhaps more. Also, I > want to know how hard you guys think it would be. 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. Or get a server that supports some sort of kvm/console over IP.
Boot network for remote unlock of fde
Hi, I have one linux server that has full disk encryption, and I use it's initramfs with dropbear to be able to remote unlock the encrypted root partition. From what I read from the OpenBSD documentation, this is not possible now. I want some guidance for what areas of code I would need to modify, to accomplish the same. I know it would involve lots of hacking with boot(8), with the kernel itself, and perhaps more. Also, I want to know how hard you guys think it would be. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
