Protection of boot sector and embedded area

Protection of boot sector and embedded area

[James Courtier-Dutton]

Hi

Is there a setting for grub-install/grub-setup where, if set, will
never actually over write the boot sector and embedded area of my HD?
I don't mind grub.conf being written to, I just do not want the boot
up executables written to.
For example, if I have an Ubuntu install, and the grub package gets
upgraded, is there a way to stop the automatic update from attacking
the boot and embedded area of my HD?

Kind Regards

James

Re: Protection of boot sector and embedded area

[Colin Watson]

On Sat, Sep 26, 2009 at 09:28:12AM +0100, James Courtier-Dutton wrote:
> Is there a setting for grub-install/grub-setup where, if set, will
> never actually over write the boot sector and embedded area of my HD?
> I don't mind grub.conf being written to, I just do not want the boot
> up executables written to.
> For example, if I have an Ubuntu install, and the grub package gets
> upgraded, is there a way to stop the automatic update from attacking
> the boot and embedded area of my HD?

At the moment, this is a recipe for GRUB becoming unusable, as the
interface between the core image and grub.cfg is not yet stable. As
such, I expect that the Ubuntu package will be changing to make this
harder to do by accident.

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: Protection of boot sector and embedded area

[James Courtier-Dutton]

2009/9/26 Colin Watson <cjwatson@ubuntu.com>:
> On Sat, Sep 26, 2009 at 09:28:12AM +0100, James Courtier-Dutton wrote:
>> Is there a setting for grub-install/grub-setup where, if set, will
>> never actually over write the boot sector and embedded area of my HD?
>> I don't mind grub.conf being written to, I just do not want the boot
>> up executables written to.
>> For example, if I have an Ubuntu install, and the grub package gets
>> upgraded, is there a way to stop the automatic update from attacking
>> the boot and embedded area of my HD?
>
> At the moment, this is a recipe for GRUB becoming unusable, as the
> interface between the core image and grub.cfg is not yet stable. As
> such, I expect that the Ubuntu package will be changing to make this
> harder to do by accident.
>
I suppose I have a special case.
My HD already has a custom boot sector and embedded area doing
something else. So I cannot install grub there at all.
I am currently installing grub onto a usb stick and booting Linux from
the usb stick, with the usb stick just doing the grub bit for me.
I want to make sure that if I do automatic upgrades in ubuntu, it will
never accidentally wipe the custom boot sector and embedded areas of
my HD.
I will manually do grub-install to update the grub on my usb stick.

Re: Protection of boot sector and embedded area

[Colin Watson]

On Sat, Sep 26, 2009 at 10:07:41AM +0100, James Courtier-Dutton wrote:
> 2009/9/26 Colin Watson <cjwatson@ubuntu.com>:
> > At the moment, this is a recipe for GRUB becoming unusable, as the
> > interface between the core image and grub.cfg is not yet stable. As
> > such, I expect that the Ubuntu package will be changing to make this
> > harder to do by accident.
> 
> I suppose I have a special case.
> My HD already has a custom boot sector and embedded area doing
> something else. So I cannot install grub there at all.
> I am currently installing grub onto a usb stick and booting Linux from
> the usb stick, with the usb stick just doing the grub bit for me.
> I want to make sure that if I do automatic upgrades in ubuntu, it will
> never accidentally wipe the custom boot sector and embedded areas of
> my HD.
> I will manually do grub-install to update the grub on my usb stick.

In future I hope that it'll be possible to tell the package to use the
USB stick in a way which is safe - i.e. it definitely won't use the hard
disk. Of course, it might object to the USB stick going missing ...

In any case, run 'sudo dpkg-reconfigure grub-pc' and make sure no
devices are selected for the "GRUB install devices:" question.

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: Protection of boot sector and embedded area

[James Courtier-Dutton]

2009/9/26 Colin Watson <cjwatson@ubuntu.com>:
>
> In any case, run 'sudo dpkg-reconfigure grub-pc' and make sure no
> devices are selected for the "GRUB install devices:" question.
>
Thank you. Just out of interest, where is the answer to that question stored?
Just to clarify, by selecting "no devices", grub boot sector will
never be installed/upgraded automatically?

Re: Protection of boot sector and embedded area

[Felix Zielcke]

Am Samstag, den 26.09.2009, 11:40 +0100 schrieb James Courtier-Dutton:
> 2009/9/26 Colin Watson <cjwatson@ubuntu.com>:
> >
> > In any case, run 'sudo dpkg-reconfigure grub-pc' and make sure no
> > devices are selected for the "GRUB install devices:" question.
> >
> Thank you. Just out of interest, where is the answer to that question stored?

Inside the debconf database.
/var/cache/debconf/

> Just to clarify, by selecting "no devices", grub boot sector will
> never be installed/upgraded automatically?

Yes

-- 
Felix Zielcke
Proud Debian Maintainer

Re: Protection of boot sector and embedded area

[Vladimir 'phcoder' Serbinenko]

James Courtier-Dutton wrote:
> 2009/9/26 Colin Watson <cjwatson@ubuntu.com>:
>   
>> On Sat, Sep 26, 2009 at 09:28:12AM +0100, James Courtier-Dutton wrote:
>>     
>>> Is there a setting for grub-install/grub-setup where, if set, will
>>> never actually over write the boot sector and embedded area of my HD?
>>> I don't mind grub.conf being written to, I just do not want the boot
>>> up executables written to.
>>> For example, if I have an Ubuntu install, and the grub package gets
>>> upgraded, is there a way to stop the automatic update from attacking
>>> the boot and embedded area of my HD?
>>>       
>> At the moment, this is a recipe for GRUB becoming unusable, as the
>> interface between the core image and grub.cfg is not yet stable. As
>> such, I expect that the Ubuntu package will be changing to make this
>> harder to do by accident.
>>
>>     
> I suppose I have a special case.
> My HD already has a custom boot sector and embedded area doing
> something else. So I cannot install grub there at all.
>   
It's generally a bad idea to chase grub out of MBR+embed area. It often
results in unreliable configurations. Could you detail your usecase so
we can seek for a bettere solution?
> I am currently installing grub onto a usb stick and booting Linux from
> the usb stick, with the usb stick just doing the grub bit for me.
> I want to make sure that if I do automatic upgrades in ubuntu, it will
> never accidentally wipe the custom boot sector and embedded areas of
> my HD.
> I will manually do grub-install to update the grub on my usb stick.
>
>   
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   

Re: Protection of boot sector and embedded area

[James Courtier-Dutton]

2009/9/26 Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>:
> It's generally a bad idea to chase grub out of MBR+embed area. It often
> results in unreliable configurations. Could you detail your usecase so
> we can seek for a bettere solution?

The other thing sitting in the embedded area is a whole disc encryption product.
It takes up about 60 sectors of the 64 sectors of the embedded area.
I don't think that there is a standard way of managing who has
priority over the embedded area.
I think it would be good if one could put grub into the beginning of a
partition.
The problem with this is that I don't know if there is room to put
grub at the beginning of an ext3
 or lvm partition. If it were possible, it would make grub much more
compatible with Dual boot systems.

Re: Protection of boot sector and embedded area

[Vladimir 'phcoder' Serbinenko]

James Courtier-Dutton wrote:
> 2009/9/26 Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>:
>   
>> It's generally a bad idea to chase grub out of MBR+embed area. It often
>> results in unreliable configurations. Could you detail your usecase so
>> we can seek for a bettere solution?
>>     
>
> The other thing sitting in the embedded area is a whole disc encryption product.
> It takes up about 60 sectors of the 64 sectors of the embedded area.
>   
I guess you speak about truecrypt. In this case the solution I would
recommend is to make grub load truecrypt's embedding area from a file on
the disk (it probably can be extracted from truecrypt w/o installing
booter). It's not a difficult task, just nobody did it yet (volunteers
are welcome).
Beware that truecrypt is distributed under a license which has legal
danger to the end user.
https://fedoraproject.org/wiki/ForbiddenItems#TrueCrypt
Of course it's your choice to use it or not but I would suggest to avoid
such software especially for the data you need to protect
> I don't think that there is a standard way of managing who has
> priority over the embedded area.
> I think it would be good if one could put grub into the beginning of a
> partition.
> The problem with this is that I don't know if there is room to put
> grub at the beginning of an ext3
>  or lvm partition. If it were possible, it would make grub much more
> compatible with Dual boot systems.
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   

Re: Protection of boot sector and embedded area

[Vladimir 'phcoder' Serbinenko]

James Courtier-Dutton wrote:
> I think it would be good if one could put grub into the beginning of a
> partition.
> The problem with this is that I don't know if there is room to put
> grub at the beginning of an ext3
>  or lvm partition. If it were possible, it would make grub much more
> compatible with Dual boot systems.
>   
Some partitions like reiserfs (64K reserved for bootloader) and lvm
("unusable space") have some space where core.img can be hold but such
cases are a minority.
XFS doesn't even have space for boot sector.
ext* has only 2 sectors available. Too few.
FAT32 has ~16K reserved. Too few.
ZFS has 8K reserved. Too few.

>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   

Re: Protection of boot sector and embedded area

[James Courtier-Dutton]

2009/9/26 Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>:
> James Courtier-Dutton wrote:
>> 2009/9/26 Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>:
>>
>>> It's generally a bad idea to chase grub out of MBR+embed area. It often
>>> results in unreliable configurations. Could you detail your usecase so
>>> we can seek for a bettere solution?
>>>
>>
>> The other thing sitting in the embedded area is a whole disc encryption product.
>> It takes up about 60 sectors of the 64 sectors of the embedded area.
>>
> I guess you speak about truecrypt. In this case the solution I would
> recommend is to make grub load truecrypt's embedding area from a file on
> the disk (it probably can be extracted from truecrypt w/o installing
> booter). It's not a difficult task, just nobody did it yet (volunteers
> are welcome).
> Beware that truecrypt is distributed under a license which has legal
> danger to the end user.
> https://fedoraproject.org/wiki/ForbiddenItems#TrueCrypt
> Of course it's your choice to use it or not but I would suggest to avoid
> such software especially for the data you need to protect

It is not truecrypt.
I would argue that a "full disk encryption" product should be in the
boot sector/embedded area and everything else, even grub should load
after it.

Re: Protection of boot sector and embedded area

[Vladimir 'phcoder' Serbinenko]

James Courtier-Dutton wrote:
> 2009/9/26 Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>:
>   
>> James Courtier-Dutton wrote:
>>     
>>> 2009/9/26 Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>:
>>>
>>>       
>>>> It's generally a bad idea to chase grub out of MBR+embed area. It often
>>>> results in unreliable configurations. Could you detail your usecase so
>>>> we can seek for a bettere solution?
>>>>
>>>>         
>>> The other thing sitting in the embedded area is a whole disc encryption product.
>>> It takes up about 60 sectors of the 64 sectors of the embedded area.
>>>
>>>       
>> I guess you speak about truecrypt. In this case the solution I would
>> recommend is to make grub load truecrypt's embedding area from a file on
>> the disk (it probably can be extracted from truecrypt w/o installing
>> booter). It's not a difficult task, just nobody did it yet (volunteers
>> are welcome).
>> Beware that truecrypt is distributed under a license which has legal
>> danger to the end user.
>> https://fedoraproject.org/wiki/ForbiddenItems#TrueCrypt
>> Of course it's your choice to use it or not but I would suggest to avoid
>> such software especially for the data you need to protect
>>     
>
> It is not truecrypt.
> I would argue that a "full disk encryption" product should be in the
> boot sector/embedded area and everything else, even grub should load
> after it.
>
>   
It has no benefit other than giving you a wrong impression of additional
security (feel free to expose your arguments). Actually having grub
before disk encryption is beneficial for configuration purposes
(encryption program is only loaded when needed)
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   

Re: Protection of boot sector and embedded area

[Michal Suchanek]

2009/9/27 James Courtier-Dutton <james.dutton@gmail.com>:
> 2009/9/26 Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>:
>> James Courtier-Dutton wrote:
>>> 2009/9/26 Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>:
>>>
>>>> It's generally a bad idea to chase grub out of MBR+embed area. It often
>>>> results in unreliable configurations. Could you detail your usecase so
>>>> we can seek for a bettere solution?
>>>>
>>>
>>> The other thing sitting in the embedded area is a whole disc encryption product.
>>> It takes up about 60 sectors of the 64 sectors of the embedded area.
>>>
>> I guess you speak about truecrypt. In this case the solution I would
>> recommend is to make grub load truecrypt's embedding area from a file on
>> the disk (it probably can be extracted from truecrypt w/o installing
>> booter). It's not a difficult task, just nobody did it yet (volunteers
>> are welcome).
>> Beware that truecrypt is distributed under a license which has legal
>> danger to the end user.
>> https://fedoraproject.org/wiki/ForbiddenItems#TrueCrypt
>> Of course it's your choice to use it or not but I would suggest to avoid
>> such software especially for the data you need to protect
>
> It is not truecrypt.
> I would argue that a "full disk encryption" product should be in the
> boot sector/embedded area and everything else, even grub should load
> after it.
>

Obviously your encryption solution does not encrypt the linux volume
which you boot using the USB stick so it has no reason to be loaded
when loading Linux, it can only cause harm by trying to decrypt what
is not encrypted.

Also as Grub can access the disk drives by various means (BIOS, PCI
device driver, ...) the encryption software would have to hijack all
these access paths transparently which I can't imagine happening.

Thanks

Michal

Re: Protection of boot sector and embedded area

[James Courtier-Dutton]

2009/9/27 Michal Suchanek <hramrach@centrum.cz>:
>
> Obviously your encryption solution does not encrypt the linux volume
> which you boot using the USB stick so it has no reason to be loaded
> when loading Linux, it can only cause harm by trying to decrypt what
> is not encrypted.
You make a assumption that the encryption program would cause harm. It does not.
One specifies which partitions to encrypt/decrypt and it leaves the rest alone.

>
> Also as Grub can access the disk drives by various means (BIOS, PCI
> device driver, ...) the encryption software would have to hijack all
> these access paths transparently which I can't imagine happening.
>
One would obviously need grub to only use BIOS calls and no direct PCI
device access for it to work together with the whole disc encryption
program in pre-boot stages. Alternatively, one would have to add
encryption support into grub itself that is not a good idea.
I think that maybe being able to install grub into it's own small
partition instead of the embedded area would be all I would need.

Kind Regards

James

Re: Protection of boot sector and embedded area

[Vladimir 'phcoder' Serbinenko]

James Courtier-Dutton wrote:
> 2009/9/27 Michal Suchanek <hramrach@centrum.cz>:
>   
>> Obviously your encryption solution does not encrypt the linux volume
>> which you boot using the USB stick so it has no reason to be loaded
>> when loading Linux, it can only cause harm by trying to decrypt what
>> is not encrypted.
>>     
> You make a assumption that the encryption program would cause harm. It does not.
> One specifies which partitions to encrypt/decrypt and it leaves the rest alone.
>
>   
It's loaded uselessly. Actually normally there is no reason to encrypt
any of the files grub accesses. But authenticating files is needed.
(encryption doesn't prevent attacker from modifying files)
Encrypting is to keep secret
MAC or signatures is to keep unmodified.
GRUB and most OSes we support are free software so there is no reason to
keep them secret. Even proprietary for kernels you have, the binaries
aren't secret.
There are two reason full disk encryption exists:
1) "I have everything encrypted" is a good confidence-giving sentence
and good for marketing
2) If you encrypt everything you have no risk of forgetting encrypting
something (typical examples: swap, /tmp, /var/tmp). This renders the
approach fool-proof and easy to configure
>> Also as Grub can access the disk drives by various means (BIOS, PCI
>> device driver, ...) the encryption software would have to hijack all
>> these access paths transparently which I can't imagine happening.
>>
>>     
> One would obviously need grub to only use BIOS calls and no direct PCI
> device access for it to work together with the whole disc encryption
> program in pre-boot stages. 
The only reason we keep BIOS calls by default is that our own drivers
don't work in all configurations.
> Alternatively, one would have to add
> encryption support into grub itself that is not a good idea.
>   
We have patches to do so. While encrypting a part of bootloader and a
kernel isn't security-improving, it renders encrypted configuration
easier (no need for separate /boot). So I'm favorable to it. Why do you
say it's a bad idea?
Signatures in grub are on todo list.
> I think that maybe being able to install grub into it's own small
> partition instead of the embedded area would be all I would need.
>   
I explained why this "all I need" is problematic
> Kind Regards
>
> James
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>