On Tue, May 14, 2019 at 07:20:15PM +0200, Roberto Sassu wrote: > On 5/14/2019 6:58 PM, Greg KH wrote: > > On Tue, May 14, 2019 at 06:33:29PM +0200, Roberto Sassu wrote: > >> Right, the measurement/signature verification of the kernel image is > >> sufficient. > >> > >> Now, assuming that we defer the IMA initialization until /init in the > >> embedded initramfs has been executed, the problem is how to handle > >> processes launched with the user mode helper or files directly read by > >> the kernel (if it can happen before /init is executed). If IMA is not > >> yet enabled, these operations will be performed without measurement and > >> signature verification. > > > > If you really care about this, don't launch any user mode helper > > programs (hint, you have the kernel option to control this and funnel > > everything into one, or no, binaries). And don't allow the kernel to > > read any files either, again, you have control over this. > > > > Or start IMA earlier if you need/want/care about this. > > Yes, this is how it works now. It couldn't start earlier than > late_initcall, as it has to wait until the TPM driver is initialized. > > Anyway, it is enabled at the time /init is executed. And this would be > an issue because launching /init and reading xattrs from /.xattr-list > would be denied (the signature is missing). > > And /.xattr-list won't have a signature, if initramfs is generated > locally. > > Roberto > > -- > HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 > Managing Director: Bo PENG, Jian LI, Yanli SHI The uevent and firmware loader user mode helpers are both obsolete I believe, so those shouldn't be an issue. There is still the internal firmware loader (CONFIG_FW_LOADER). If this is built-in, there's probably no way to 100% stop it racing with /init if we depend on an embedded /init and a malicious external initramfs image contains /lib/firmware, but it can be built as an external module, in which case there should be no danger until the boot process actually loads it.
