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