On Wed, 2013-01-30 at 06:32 +0000, Matthew Garrett wrote: > On Tue, Jan 29, 2013 at 11:58:53AM -0500, Vivek Goyal wrote: > > On Mon, Jan 28, 2013 at 08:48:55PM -0500, Mimi Zohar wrote: > > > The assumption has always been that the initramfs would be measured, for > > > trusted boot, and appraised, for secure boot, before being executed. > > > > Hi Mimi, > > > > Ok. So for trusted boot, if initramfs is changed it will be detected. For > > secureboot, atleast right now initramfs is not signed and appraised. But > > I guess it could be added. > > > > But initramfs is generated by installer and installer does not have > > private keys to sign it. So distributions could not sign initramfs. > > Right, there's a whole range of problems here. The first is that the > initramfs has to contain the full set of drivers required to boot a > given piece of hardware, and the precise set required varies between > machines. Building a truly generic initramfs would result in > significantly larger images. > > There's also an existing expectation that it be possible to break into > initramfs execution for debugging purposes. Even ignoring that, most > initramfs implementations aren't expected to be hardened against a user > inserting shell control characters into the kernel command line. It > would require significant engineering work to ensure that there's no way > for an attacker to cause code execution before the key store has been > locked. > > Shipping prebuilt initramfses is also difficult from a release > engineering perspective. You'd need to keep track of the software > versions that were included in the initramfs and ensure that the > initramfs is rebuilt if any of those pieces of software are updated > between the initramfs being generated and the software being shipped. > Version skew could cause subtle bugs and also makes license compliance > difficult. > > Finally, portions of the userspace in initramfs may be under licenses > that require it to be possible for the end user to replace components. > This isn't a problem as long as the keys in MOK can be used. > > There's additional small problems, like the initramfs containing the > bootsplash theme and users expecting to be able to change that without > having to generate crypto keys, but that's probably not a showstopper. > But realistically, the first three problems make it unlikely that most > distributions will be willing to depend on or ship pre-built initramfs > images. Ok. From an IMA-appraisal perspective, either the contents of the initramfs have to be signed or the initramfs, itself, must be signed. Otherwise there is a break in the secure boot chain. Unfortunately, unlike the bsdcpio package, which has formats that support extended attributes, the cpio package does not. Similar to modules, in order to not break the secure boot signature chain, the IMA-appraisal and EVM keys can be built into the kernel. Patches were posted a while ago https://lkml.org/lkml/2012/8/15/376, but have not been upstreamed. evm: initialize the _evm public key keyring ima: initialize the _ima public keyring integrity: create and inititialize a keyring with builtin public key keys: initialize root uid and session keyrings early These patches will need to be updated to reflect recent keyring changes. thanks, Mimi -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
