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 initramfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
