Message-ID: <54B5913C.5050109@landley.net>
Date:	Tue, 13 Jan 2015 15:42:20 -0600
From:	Rob Landley <rob@...dley.net>
To:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
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>
Subject: Re: [RFC][PATCH 6/9] gen_initramfs_list.sh: include xattrs



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)?

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

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