Re: [Linux-ima-user] Initramfs and IMA Appraisal

[Rob Landley <rob@landley.net>]

On 12/29/2014 09:20 PM, Mimi Zohar wrote:
> On Mon, 2014-12-29 at 19:55 -0600, Rob Landley wrote: 
>>> Thanks Rob for the explanation.  The problem is that ramfs does not
>>> support extended attributes, while tmpfs does.
>>
>> If you're _using_ initramfs/initmpfs, there's no reason to specify a root=.
> 
> The menu entry looks like:
> linux   /vmlinuz-3.17.0+ root=UUID=94595ff7-0fd4-4ea3-99f2-f7ddf8fbc91f
> ro  ...
> initrd  /initramfs-3.17.0+.img
> 
> Because "root=" is specified, rootfs is not using tmpfs.

Yes. Pilot error.

If you want tmpfs to switch to UUID $THINGY you can do ROOT= and have it
use that. You're asking for something to be interpreted by the kernel
sometimes and passed on to userspace other times and have no side
effects even though it's interpeted by the kernel.

>>> The boot loader could
>>> "measure" (trusted boot) the initramfs, but as the initramfs is
>>> generated on the target system, the initramfs is not signed, preventing
>>> it from being appraised (secure Boot). To close the initramfs integrity
>>> appraisal gap requires verifying the individual initramfs file
>>> signatures, which are stored as extended attributes.
>>
>> Faced with the phrases "trusted boot" and "integrity appraisal", I plead
>> the third.
> 
> Fine.  Bottom line, rootfs needs to support extended attributes.

I added a patch to make it work as tmpfs a year ago. You now know what
trivial configuration mistake you make that's preventing it from
working. If you'd like me to submit a documentation update patch to make
it easier to avoid in future, I can do that.

>> (In the wake of the Snowden infodump,
> 
> All the more reason to allow only those files that are properly signed
> to be read/executed.

Using the infrastructure the NSA provided, which is intentionally so
complicated that "you are not expected to understand this".

Good luck with that.

> Mimi

Rob