Message-ID: <1421205803.2119.110.camel@dhcp-9-2-203-236.watson.ibm.com>
Date:	Tue, 13 Jan 2015 22:23:23 -0500
From:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
To:	Rob Landley <rob@...dley.net>
Cc:	Josh Boyer <jwboyer@...oraproject.org>,
	initramfs <initramfs@...r.kernel.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	linux-ima-devel@...ts.sourceforge.net,
	linux-security-module <linux-security-module@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Fionnuala Gunter <fin@...ux.vnet.ibm.com>,
	"casey.schaufler" <casey.schaufler@...el.com>,
	Paul Moore <pmoore@...hat.com>
Subject: Re: [RFC][PATCH 6/9] gen_initramfs_list.sh: include xattrs

On Tue, 2015-01-13 at 15:42 -0600, Rob Landley wrote: 
> 
> On 01/13/2015 02:20 PM, Mimi Zohar wrote:
> > On Tue, 2015-01-13 at 12:48 -0600, Rob Landley wrote: 
> >> I note that there are two data formats of interest here:
> >>
> >> 1) the cpio file layout.
> >>
> >> 2) the list of files generated by gen_initramfs_list.sh and consumed by
> >> gen_init_cpio.
> >>
> >> The fact you're modifying gen_initramfs_list.sh seems to imply that
> >> you're changing the _second_ format as well as the first...? The second
> >> was never actually specified, but it does get used a lot by various
> >> build systems and breaking it would inconvenience people. (Plus I'd need
> >> to update the documentation, but I need to do that anyway.)
> > 
> > Patch "[PATCH 6/9] gen_initramfs_list.sh: include xattrs" is a one line
> > change that adds the "-x" option to include xattrs in the initramfs, if
> > they exist.
> 
> Unconditionally. Even if we've configured xattr support out of our
> kernel or tmpfs?
> 
> > This patch makes the new method (070703) the default format.
> 
> So nobody should ever try to build an embedded system (without xattrs)
> from something like Red Hat Enterprise (where they just magically show up)?

Good point.  I'll address this in the next post.

> >> Ss long as you're extending the format could you add a second 32 bits of
> >> time data that gets glued to the top half of a uint64_t, and then store
> >> the actual time value in microseconds (so time*1000000)? (I'd say
> >> "nanoseconds" but 63 bits of nanoseconds is 292 years, which is just
> >> short enough I'm uncomfortable with it. I'm just optimistic enough to
> >> think that might inconvenience somebody.)
> >>
> >> The other "huh" is the filesize, but 4 gigs per file seems unlikely to
> >> be more than initramfs needs any time soon? (It's possible that RPM
> >> might care in 15 years or so...)
> > 
> > 4 bytes enough?

> Eh, as long as we're breaking compatibility anyway, we might as well
> extend the file size. It's gzipped so the extra run of consecutive
> zeroes isn't really an issue, and if tmpfs is going to support 64 bit
> file sizes the thing that's populating them should to just to match.
> (You can already have memory bigger than 4g. Some crazy person is going
> to put a squashfs in tmpfs and loopback mount it, or have a giant video
> there, or... Bootloaders being able to cope with this is not my problem. :)

> Probably having the new fields at the end (and gluing them to the
> earlier ones) makes more sense than having variable sized fields? I
> don't have a strong opinion either way.

The current file data size header field is a 8 character hexidecimal
string, which is long enough to store 4g (0xFFFFFFFF).

> >> I have no idea what sys_setxattr() accepts, but
> >> presumably there's a man page for the system call...
> >>
> >>   http://man7.org/linux/man-pages/man2/setxattr.2.html
> >>
> >> Ok, that's probably enough data to implement it. (Not sure why that man
> >> page isn't in my ubuntu 14.04 install which has manpages-dev installed?
> >>
> >>   $ man setxattr
> >>   No manual entry for setxattr
> >>
> >>> Note that gen_init_cpio does not include "security.evm" as it is file
> >>> system dependent.
> >>
> >> I have no idea what that is. Should I not include it in the command line
> >> cpio? (Or have a flag?)
> > 
> > Right, don't include "security.evm".  Both the HMAC and signature format
> > include the inode number, which is filesystem specific.
> 
> So save extended attributes but filter out this one magic extended
> attribute that we _shouldn't_ save because we know, a priori, that this
> data is not portable.
> 
> I'm remembering why I didn't want to get this on me.
> 
> >> The last time I used extended attributes was on OS/2; my only
> >> non-academic interaction with selinux has been looking up how to switch
> >> it off.
> >>
> >> I still boggle that Fortune 500 bureaucracies include "must have a
> >> security system designed by the NSA based on the idea of complicating
> >> the system until there are no obvious holes, because after the Snowden
> >> leaks that's clearly a good idea" as part of their certification
> >> processes for reducing the risk of being unable to delegate blame.
> > 
> > I'm the linux-integrity subsystem maintainer, not an LSM maintainer (not
> > that there is anything wrong in being an LSM maintainer).  So, I'm not
> > quite sure why you keep saying things like this to me. BTW, there are
> > a number of LSMs these days, not only SELinux.
> 
> Yes, and I can't keep 'em straight. The android guys are adding SELinux:
> 
> https://android.googlesource.com/platform/external/toybox/+/d5c66a9fd36777f80ba05301dcfa6789b103e486
> 
> The Tizen guys are adding something called "smack":
> https://git.tizen.org/cgit/platform/upstream/toybox.git
> 
> Up until about 3 months ago I had successfully avoided all of this. Oh
> well, always something new to learn...
> 
> Do each of them have their own rules about what extended attribute data
> is not portable and should be filtered out? Or is this one magic entry
> it? (I'd RTFM but http://man7.org/linux/man-pages/man5/attr.5.html does
> not contain the string "evm".)
> 
> Rob

I would assume only 'security.evm' is not portable as it attempts to
tightly bind the file metadata to the file data.  Casey?  Paul?

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/

Powered by blists - more mailing lists