[RFC] Boot parameters and geometrical stability

[RFC] Boot parameters and geometrical stability

[phcoder]

Hello, all.
Now when core image can be booted by multiple sources perhaps it would
be a good idea to recieve some boot arguments in case boot method (e.g.
multiboot) supports it. Probably the best way is to recieve pairs
<name,value> which can be easily imported to environment. Another
possibility of improving boot process is to detect the prefix even if
partition map changed it can be done e.g. with UUID but this comprises a
security risk in case an attacker can plug a device (cdrom, floppy,
USB-memory,..) containing a partition with the same UUID. What do you
think about it
Vladimir 'phcoder' Serbinenko

Re: [RFC] Boot parameters and geometrical stability

[Robert Millan]

On Wed, Sep 03, 2008 at 11:50:33AM +0200, phcoder wrote:
> Hello, all.
> Now when core image can be booted by multiple sources perhaps it would
> be a good idea to recieve some boot arguments in case boot method (e.g.
> multiboot) supports it. Probably the best way is to recieve pairs
> <name,value> which can be easily imported to environment.

I assume you talk about GRUB loading itself;  what kind of information would
you pass from one GRUB to the other?

> Another
> possibility of improving boot process is to detect the prefix even if
> partition map changed it can be done e.g. with UUID

We use UUIDs already, but only when drives can't be referred to unambigously,
check how grub-install does it.

> but this comprises a
> security risk in case an attacker can plug a device (cdrom, floppy,
> USB-memory,..) containing a partition with the same UUID. What do you
> think about it

I think people who want this level of security (i.e. local media is not
trusted) should use crypto checksums to verify they're loading what they
expected, with or without UUIDs.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: [RFC] Boot parameters and geometrical stability

[phcoder]

Robert Millan wrote:
> On Wed, Sep 03, 2008 at 11:50:33AM +0200, phcoder wrote:
>> Hello, all.
>> Now when core image can be booted by multiple sources perhaps it would
>> be a good idea to recieve some boot arguments in case boot method (e.g.
>> multiboot) supports it. Probably the best way is to recieve pairs
>> <name,value> which can be easily imported to environment.
> 
> I assume you talk about GRUB loading itself;  what kind of information would
> you pass from one GRUB to the other?
Boot device, configuration file, parameters for scripts. But much more
useful this is for network boot. In this case GRUB can recieve server
info in boot parameters so when this info changes there is no need to
regenerate grub images.
> 
>> but this comprises a
>> security risk in case an attacker can plug a device (cdrom, floppy,
>> USB-memory,..) containing a partition with the same UUID. What do you
>> think about it
> 
> I think people who want this level of security (i.e. local media is not
> trusted) should use crypto checksums to verify they're loading what they
> expected, with or without UUIDs.
> 
I was thinking about the scenario when ide drives are trusted but not
USB or removable devices. Cryptographic checksums wouldn't bring much
because if attacker can modify harddrive he can also modify GRUB to skip
 checksum check.
Vladimir 'phcoder' Serbinenko

Re: [RFC] Boot parameters and geometrical stability

[Vesa Jääskeläinen]

phcoder wrote:
> I was thinking about the scenario when ide drives are trusted but not
> USB or removable devices. Cryptographic checksums wouldn't bring much
> because if attacker can modify harddrive he can also modify GRUB to skip
>  checksum check.

Then you password protect it :) Once that is supported.

But really, if attacker has access to your HDD then there is not a
really reason why we should do defense against that one as they can
overwrite us at will.

Re: [RFC] Boot parameters and geometrical stability

[phcoder]

Vesa Jääskeläinen wrote:
> phcoder wrote:
>> I was thinking about the scenario when ide drives are trusted but not
>> USB or removable devices. Cryptographic checksums wouldn't bring much
>> because if attacker can modify harddrive he can also modify GRUB to skip
>>  checksum check.
> 
> Then you password protect it :) Once that is supported.
> 
> But really, if attacker has access to your HDD then there is not a
> really reason why we should do defense against that one as they can
> overwrite us at will.
But consider a scenario when attacker can't overwrite the existing
harddrive but can plug new one. Then the attacker can prepare a
harddrive having a partition with the same UUID as our boot partition.
Then he plugs it and depnding on factors like order of interfaces,
devices, phase of the moon, ... GRUB can load attacker's modules. While
it's ok to use UUID on personal desktop system when attacker can't plug
his devices it shouldn't be the default.
Vladimir 'phcoder' Serbinenko

Re: [RFC] Boot parameters and geometrical stability

[Vesa Jääskeläinen]

phcoder wrote:
> But consider a scenario when attacker can't overwrite the existing
> harddrive but can plug new one. Then the attacker can prepare a
> harddrive having a partition with the same UUID as our boot partition.
> Then he plugs it and depnding on factors like order of interfaces,
> devices, phase of the moon, ... GRUB can load attacker's modules. While
> it's ok to use UUID on personal desktop system when attacker can't plug
> his devices it shouldn't be the default.

That is a valid point.

Would you prefer to use hardware path to device or what you had in mind
then? Because this is something that we can left for expert people. Most
common problem is that user plugs in new drive to system and
bios/hardware order gets changed or something like that, and that
renders system unbootable. UUID is perfect solution for that case.

Possibilites are there, but basically they are limited to something like:

(ata0) (pci-X-Y-Z:ata0) (usb-X-Y:scsi0) (pci-X-Y-Z:scsi0)

I do not know if those all would be valid, but I hope you get the idea.

Alternative would be that you integrate some module to core that
validates your system that there is no extra devices or such.

Thanks,
Vesa Jääskeläinen

Re: [RFC] Boot parameters and geometrical stability

[phcoder]

Vesa Jääskeläinen wrote:
> That is a valid point.
> 
> Would you prefer to use hardware path to device or what you had in mind
> then? Because this is something that we can left for expert people. Most
> common problem is that user plugs in new drive to system and
> bios/hardware order gets changed or something like that, and that
> renders system unbootable. UUID is perfect solution for that case.
> 
Yes it is, but in my opinion price is too high (shame ubuntu uses this
solution). It's somewhat similar to some solutions found in windows when
  for user convenience they open a big gate for the hackers (e.g. all
users by default are administrators in winxp)
> Possibilites are there, but basically they are limited to something like:
> 
> (ata0) (pci-X-Y-Z:ata0) (usb-X-Y:scsi0) (pci-X-Y-Z:scsi0)
> 
> I do not know if those all would be valid, but I hope you get the idea.

Yes. This is a solution found in grub legacy and I think it's a good one.
> 
> Alternative would be that you integrate some module to core that
> validates your system that there is no extra devices or such.

It's bigger since you require module and has no advantages over using
hardware names. But what we can do is to check if 2 partitions share the
same UUID and if it's the case prompt for password. The problem is that
if the same device is visible twice then it will result in a false
positive. Another solution would be to checksum modules we load. But in
this case after partial update or configuration modification a run
checksum-updater is necessary or at least user will have to enter his
password on the next boot.
> 
> Thanks,
> Vesa Jääskeläinen

Vladimir 'phcoder' Serbinenko

Re: [RFC] Boot parameters and geometrical stability

[Vesa Jääskeläinen]

phcoder wrote:
> Vesa Jääskeläinen wrote:
>> That is a valid point.
>>
>> Would you prefer to use hardware path to device or what you had in mind
>> then? Because this is something that we can left for expert people. Most
>> common problem is that user plugs in new drive to system and
>> bios/hardware order gets changed or something like that, and that
>> renders system unbootable. UUID is perfect solution for that case.
>>
> Yes it is, but in my opinion price is too high (shame ubuntu uses this
> solution). It's somewhat similar to some solutions found in windows when
>   for user convenience they open a big gate for the hackers (e.g. all
> users by default are administrators in winxp)

Well... That is your opinion. I acknowledge that it opens another door
for local hacker. But if you are able to do that, then you can do some
other actions that are much more fatal...

But the gain can still supersede the security need. Its kinda same thing
that you are required to change your password monthly. People start
putting those on stickers and then the game is lost anyway.

>> Possibilites are there, but basically they are limited to something like:
>>
>> (ata0) (pci-X-Y-Z:ata0) (usb-X-Y:scsi0) (pci-X-Y-Z:scsi0)
>>
>> I do not know if those all would be valid, but I hope you get the idea.
> 
> Yes. This is a solution found in grub legacy and I think it's a good one.

We already have (hdX) and (ataY) in GRUB 2. Especially (hdX) has lots of
problems that this UUID was used to workaround.

Re: [RFC] Boot parameters and geometrical stability

[phcoder]

Vesa Jääskeläinen wrote:
> phcoder wrote:
>> Yes it is, but in my opinion price is too high (shame ubuntu uses this
>> solution). It's somewhat similar to some solutions found in windows when
>>   for user convenience they open a big gate for the hackers (e.g. all
>> users by default are administrators in winxp)
> 
> Well... That is your opinion. I acknowledge that it opens another door
> for local hacker. But if you are able to do that, then you can do some
> other actions that are much more fatal...
If attacker is unable to open computer, bios is under password, boots
only from HD and grub is password-protected than I don't see which other
action can lead to the same result (complete control of computer).
> 
> But the gain can still supersede the security need. Its kinda same thing
> that you are required to change your password monthly. People start
> putting those on stickers and then the game is lost anyway.
> 
This is eternal problem of security and its cost (see B.Schneier Beyond
Fear). If someone find this compromise of security OK on his computer
then fine. Just the user has at least to be warned about security risks
it represents and have an alternative. I think a WARNING with
description of the problem with a promt after it and possibility to do
it otherwise (with hardware path or entering the disk manually) should
be enough.

Vladimir 'phcoder' Serbinenko

Re: [RFC] Boot parameters and geometrical stability

[Robert Millan]

On Wed, Sep 03, 2008 at 08:49:14PM +0300, Vesa Jääskeläinen wrote:
> 
> Possibilites are there, but basically they are limited to something like:
> 
> (ata0) (pci-X-Y-Z:ata0) (usb-X-Y:scsi0) (pci-X-Y-Z:scsi0)

I think this is overkill, and doesn't really address the root of the problem.

The real security problem here is whether the executable code you're loading is
trusted, NOT where you load the code from.

When you use crypto checksums, if you get a match why would you care if you're
loading from (some-safe-disk) or from (evil-place)?  It's the same data!

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: [RFC] Boot parameters and geometrical stability

[phcoder]

Robert Millan wrote:
> On Wed, Sep 03, 2008 at 08:49:14PM +0300, Vesa Jääskeläinen wrote:
>> Possibilites are there, but basically they are limited to something like:
>>
>> (ata0) (pci-X-Y-Z:ata0) (usb-X-Y:scsi0) (pci-X-Y-Z:scsi0)
> 
> I think this is overkill, and doesn't really address the root of the problem.
> 
> The real security problem here is whether the executable code you're loading is
> trusted, NOT where you load the code from.
If the code is loaded from the same place as we do then we can trust it
(if attacker could modify the code, he could also modify us)
> 
> When you use crypto checksums, if you get a match why would you care if you're
> loading from (some-safe-disk) or from (evil-place)?  It's the same data!
> 
Yes it is. But I don't know how big the crypto-checksum-check module
would be.
Vladimir 'phcoder' Serbineko

Re: [RFC] Boot parameters and geometrical stability

[Robert Millan]

On Thu, Sep 04, 2008 at 11:40:32PM +0200, phcoder wrote:
> Robert Millan wrote:
> > On Wed, Sep 03, 2008 at 08:49:14PM +0300, Vesa Jääskeläinen wrote:
> >> Possibilites are there, but basically they are limited to something like:
> >>
> >> (ata0) (pci-X-Y-Z:ata0) (usb-X-Y:scsi0) (pci-X-Y-Z:scsi0)
> > 
> > I think this is overkill, and doesn't really address the root of the problem.
> > 
> > The real security problem here is whether the executable code you're loading is
> > trusted, NOT where you load the code from.
> If the code is loaded from the same place as we do then we can trust it
> (if attacker could modify the code, he could also modify us)

Right.  I was assuming you mean when code is loaded from different places.
Having untrusted code perform the verification of other untrusted code is
useless, of course.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: [RFC] Boot parameters and geometrical stability

[Robert Millan]

On Wed, Sep 03, 2008 at 02:31:10PM +0200, phcoder wrote:
> > 
> > I assume you talk about GRUB loading itself;  what kind of information would
> > you pass from one GRUB to the other?
> Boot device,

Multiboot already handles that (although it's not reliable; I don't
think this feature should be used anyway).

> configuration file, parameters for scripts.

This assumes the loader knows more than the loadee about this information.
In which situation would this happen?  Note that both loader and loadee can
obtain user input.

Which parameters do you have in mind?

> But much more
> useful this is for network boot. In this case GRUB can recieve server
> info in boot parameters so when this info changes there is no need to
> regenerate grub images.

Doesn't PXE already handle this?

> Cryptographic checksums wouldn't bring much
> because if attacker can modify harddrive he can also modify GRUB to skip
>  checksum check.

The only way to restrict physical users from privileged access is by using
physical means.  Everything else is mere obstruction.

Though, you can still run GRUB in your ROM (with coreboot), have it do the
crypto checksum from there, and restrict write access to the ROM (e.g. by
sinking it in concrete).

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: [RFC] Boot parameters and geometrical stability

[phcoder]

Robert Millan wrote:
> On Wed, Sep 03, 2008 at 02:31:10PM +0200, phcoder wrote:
>>> I assume you talk about GRUB loading itself;  what kind of information would
>>> you pass from one GRUB to the other?
>> Boot device,
> 
> Multiboot already handles that (although it's not reliable; I don't
> think this feature should be used anyway).
> 
Feature in multiboot is hmm..: it gives bios device and grub supports
also other devices.
>> configuration file, parameters for scripts.
> 
> This assumes the loader knows more than the loadee about this information.
> In which situation would this happen?  Note that both loader and loadee can
> obtain user input.
> 
> Which parameters do you have in mind?
> 
I thought of it more like about instruction like: boot from strange
place or enter debug mode in early stage.
>> But much more
>> useful this is for network boot. In this case GRUB can recieve server
>> info in boot parameters so when this info changes there is no need to
>> regenerate grub images.
> 
> Doesn't PXE already handle this?
> 
I'm not really familiar with it. Does it support multiple servers. If
let's say we have multiple menus like:
<load linux from server1 (normal copy)>
<load linux from server2 (experimental copy)>
<load freebsd from server3>
Then having recieved names of servers as parameters could sometimes be a
good thing. But still for me this feature is just an idea. I'm still not
persuaded myself whether it's needed.
Vladimir 'phcoder' Serbinenko

Re: [RFC] Boot parameters and geometrical stability

[Robert Millan]

On Thu, Sep 04, 2008 at 11:37:43PM +0200, phcoder wrote:
> Robert Millan wrote:
> > On Wed, Sep 03, 2008 at 02:31:10PM +0200, phcoder wrote:
> >>> I assume you talk about GRUB loading itself;  what kind of information would
> >>> you pass from one GRUB to the other?
> >> Boot device,
> > 
> > Multiboot already handles that (although it's not reliable; I don't
> > think this feature should be used anyway).
> > 
> Feature in multiboot is hmm..: it gives bios device and grub supports
> also other devices.

Yes.  Besides, it's only an integer, which isn't able to reliably identify
a device.  That's why I don't think this feature should be used.

> > Which parameters do you have in mind?
> > 
> I thought of it more like about instruction like: boot from strange
> place or enter debug mode in early stage.

You don't need additional parameters for that.  Since both loader and loadee
can take user input, user can tell the loadee to enter debug mode instead of
the loader (press 'c', then set debug=something, etc).

> > Doesn't PXE already handle this?
> > 
> I'm not really familiar with it. Does it support multiple servers.

Neither am I.  I think we should have a clear idea on what our requirements
for PXE are before discussing if we need to use boot parameters for it.

> But still for me this feature is just an idea. I'm still not
> persuaded myself whether it's needed.

Maybe it's a good idea, or maybe it's not useful for anything.  I think first
of all we should exactly know what it is needed for.  IMHO, we should be
careful about adding interfaces just for the sake of having them.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."