On Tue, May 14, 2019 at 07:20:15PM +0200, Roberto Sassu wrote:

On 5/14/2019 6:58 PM, Greg KH wrote:

quoted

On Tue, May 14, 2019 at 06:33:29PM +0200, Roberto Sassu wrote:

quoted

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.