Boot network for remote unlock of fde

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Boot network for remote unlock of fde

Giancarlo Razzolini-3
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

Reply | Threaded
Open this post in threaded view
|

Re: Boot network for remote unlock of fde

Ted Unangst-6
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.

Reply | Threaded
Open this post in threaded view
|

Re: Boot network for remote unlock of fde

Giancarlo Razzolini-3
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

Reply | Threaded
Open this post in threaded view
|

Re: Boot network for remote unlock of fde

Stuart Henderson-6
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 ...


Reply | Threaded
Open this post in threaded view
|

Re: Boot network for remote unlock of fde

Jean-Philippe Ouellet
In reply to this post by Ted Unangst-6
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.

Reply | Threaded
Open this post in threaded view
|

Re: Boot network for remote unlock of fde

Giancarlo Razzolini-3
In reply to this post by Stuart Henderson-6
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

Reply | Threaded
Open this post in threaded view
|

Re: Boot network for remote unlock of fde

Giancarlo Razzolini-3
In reply to this post by Jean-Philippe Ouellet
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

Reply | Threaded
Open this post in threaded view
|

Re: Boot network for remote unlock of fde

Matthieu Herrb
In reply to this post by Giancarlo Razzolini-3
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

Reply | Threaded
Open this post in threaded view
|

Re: Boot network for remote unlock of fde

Ted Unangst-6
In reply to this post by Giancarlo Razzolini-3
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.


Reply | Threaded
Open this post in threaded view
|

Re: Boot network for remote unlock of fde

Giancarlo Razzolini-3
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

Reply | Threaded
Open this post in threaded view
|

Re: Boot network for remote unlock of fde

Paul de Weerd
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/                 

Reply | Threaded
Open this post in threaded view
|

Re: Boot network for remote unlock of fde

Chris Cappuccio
In reply to this post by Giancarlo Razzolini-3
Giancarlo Razzolini [[hidden email]] 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.)

Reply | Threaded
Open this post in threaded view
|

Re: Boot network for remote unlock of fde

Damien Miller
In reply to this post by Stuart Henderson-6
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

Reply | Threaded
Open this post in threaded view
|

Re: Boot network for remote unlock of fde

Stuart Henderson-6
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)..

Reply | Threaded
Open this post in threaded view
|

Re: Boot network for remote unlock of fde

Kevin Chadwick-2
In reply to this post by Giancarlo Razzolini-3
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
_______________________________________________________________________

Reply | Threaded
Open this post in threaded view
|

Re: Boot network for remote unlock of fde

Kevin Chadwick-2
In reply to this post by Giancarlo Razzolini-3
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
_______________________________________________________________________

Reply | Threaded
Open this post in threaded view
|

Re: Boot network for remote unlock of fde

Giancarlo Razzolini-3
In reply to this post by Chris Cappuccio
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

Reply | Threaded
Open this post in threaded view
|

Re: Boot network for remote unlock of fde

Ted Unangst-6
In reply to this post by Giancarlo Razzolini-3
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.

Reply | Threaded
Open this post in threaded view
|

Re: Boot network for remote unlock of fde

Giancarlo Razzolini-3
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

Reply | Threaded
Open this post in threaded view
|

Re: Boot network for remote unlock of fde

Theo de Raadt
In reply to this post by Giancarlo Razzolini-3
> 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 ...

12