Re: Protection of boot sector and embedded area
2009/9/27 James Courtier-Dutton james.dut...@gmail.com: 2009/9/26 Vladimir 'phcoder' Serbinenko phco...@gmail.com: James Courtier-Dutton wrote: 2009/9/26 Vladimir 'phcoder' Serbinenko phco...@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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Protection of boot sector and embedded area
2009/9/27 Michal Suchanek hramr...@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 ___ 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 wrote: 2009/9/27 Michal Suchanek hramr...@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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Protection of boot sector and embedded area
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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Protection of boot sector and embedded area
2009/9/26 Colin Watson cjwat...@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. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Protection of boot sector and embedded area
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 [cjwat...@ubuntu.com] ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Protection of boot sector and embedded area
2009/9/26 Colin Watson cjwat...@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? ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Protection of boot sector and embedded area
Am Samstag, den 26.09.2009, 11:40 +0100 schrieb James Courtier-Dutton: 2009/9/26 Colin Watson cjwat...@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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Protection of boot sector and embedded area
On Sat, Sep 26, 2009 at 10:07:41AM +0100, James Courtier-Dutton wrote: 2009/9/26 Colin Watson cjwat...@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 [cjwat...@ubuntu.com] ___ 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 wrote: 2009/9/26 Colin Watson cjwat...@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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Protection of boot sector and embedded area
2009/9/26 Vladimir 'phcoder' Serbinenko phco...@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. ___ 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 wrote: 2009/9/26 Vladimir 'phcoder' Serbinenko phco...@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 ___ 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 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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Protection of boot sector and embedded area
2009/9/26 Vladimir 'phcoder' Serbinenko phco...@gmail.com: James Courtier-Dutton wrote: 2009/9/26 Vladimir 'phcoder' Serbinenko phco...@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. ___ 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 wrote: 2009/9/26 Vladimir 'phcoder' Serbinenko phco...@gmail.com: James Courtier-Dutton wrote: 2009/9/26 Vladimir 'phcoder' Serbinenko phco...@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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
