lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Mon, 29 Dec 2014 22:17:32 -0600
From:	Rob Landley <>
To:	Mimi Zohar <>
CC:	Christophe Fillot <>,,
	linux-security-module <>,
	linux-kernel <>
Subject: Re: [Linux-ima-user] Initramfs and IMA Appraisal

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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists