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

lists.openwall.net		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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 29 Dec 2014 22:20:49 -0500
From:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
To:	Rob Landley <rob@...dley.net>
Cc:	Christophe Fillot <cf@....fr>,
	linux-ima-user@...ts.sourceforge.net,
	linux-security-module <linux-security-module@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [Linux-ima-user] Initramfs and IMA Appraisal

On Mon, 2014-12-29 at 19:55 -0600, Rob Landley wrote: 
> 
> On 12/29/2014 03:46 PM, Mimi Zohar wrote:
> > On Mon, 2014-12-29 at 14:34 -0600, Rob Landley wrote: 
> >> On 12/29/2014 07:45 AM, Mimi Zohar wrote:
> >>> On Thu, 2014-11-27 at 10:15 +0100, Christophe Fillot wrote:
> >>>>>
> >>>>> Are you using an initrd not an initramfs?  According to
> >>>>> Documentation/filesystems/ramfs-rootfs-initramfs.txt, "If
> >>>> CONFIG_TMPFS
> >>>>> is enabled, rootfs will use tmpfs instead of ramfs by default".
> >>>>>
> >>>> Yes, that what I thought too, but it seems that it is not really the 
> >>>> case because of this test:
> >>>>
> >>>>      if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] &&
> >>>>          (!root_fs_names || strstr(root_fs_names, "tmpfs"))) {
> >>>>          err = shmem_init();
> >>>>          is_tmpfs = true;
> >>>>      } else {
> >>>>          err = init_ramfs_fs();
> >>>>      }
> >>>
> >>> [CC'ing Rob Landley, lsm, lkml]
> >>>
> >>> Thanks!  "saved_root_name" is set to the boot command line "root="
> >>> option, which in my case is the UUID.  I'm not sure why real root should
> >>> impact the initramfs tmpfs/ramfs decision.
> >>>
> >>> Unless there is a good explanation, did you want to post a patch to
> >>> remove the test?
> >>
> >> I added support last year, here's the start of the patch series:
> >>
> >>   https://lkml.org/lkml/2013/6/29/101
> >>
> >> The logic is that if you specify a fallback root via root=, then you're
> >> not staying on rootfs (that's what root= _means_, "here is the root
> >> filesystem the kernel is to mount over rootfs"), and thus the extra
> >> infrastructure for tmpfs instead of ramfs is unnecessary.
> > 
> > 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.

> > 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.

> (In the wake of the Snowden infodump,

All the more reason to allow only those files that are properly signed
to be read/executed.

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/