Thanks again, this is all very helpful. One point is that while the cpio format does not support extended attributes the actual ram disk that is mounted by Linux does. Not sure if that changes your answer any. Thanks, Ian > On Oct 23, 2020, at 6:37 PM, William Roberts <bill.c.roberts@xxxxxxxxx> wrote: > > On Fri, Oct 23, 2020 at 5:20 PM Ian M <merinian@xxxxxxxxx> wrote: >> >> Thanks, cpio supporting extended attributes would be very helpful right now. >> >> After looking through the ref policy I see there is a genfscon statement for rootfs which is what is labeling everything as root_t. > > Yeah, genfscon is the way to say, hey this filesystem, all things have > this label. genfscon takes paths, for more specific labelling, > IIRC, cannot be used on rootfs; that feature only works for proc/sysfs > like pseudo filesystems. > >> >> Would I break everything terribly if I removed that and setup an fs_use_xattr for the rootfs? > > Yes because there is no xattr support, so it would choke and die when > the kernel wants the xattr. > > Here's some other things to consider: > 1. There is no xattr support. You would need to see if that patch or > something equivalent was accepted and then what kernel > version, and determine if your kernel supports it. Then at build > time for the image you would have to create that dotfile that contains > the > labels and package it in the CPIO archive. Then you could use the > fs_use_xattr IIUC. > 2. I could be mistaken, but I think in recent years I have seen > patches or articles that other FS types can be used for the initial > root filesystem > now without a need for initrd, so you could, IIUC, boot directly > into a labelled ext4 filesystem. You would have to label that file > system during build. > 3. Most linuxt things boot into an initrd and then pivot to the actual > root filesystem, you could do that as well. > > This would take some digging likely to figure out, or find someone > that knows way more than me. That shouldn't be too terribly hard, > I don't know much. > >> >> >> Thanks, >> >> Ian Merin >> >>>> On Oct 23, 2020, at 3:49 PM, William Roberts <bill.c.roberts@xxxxxxxxx> wrote: >>> >>> On Fri, Oct 23, 2020 at 2:05 PM James Carter <jwcart2@xxxxxxxxx> wrote: >>>> >>>>> On Fri, Oct 23, 2020 at 12:02 PM Ian M <merinian@xxxxxxxxx> wrote: >>>>> >>>>> Hello, >>>>> >>>>> I hope this is the right list for this question: >>>>> >>>>> I've got an embedded system that uses its initramfs as its root filesystem as well. At boot, after the selinux policy loads, everything on the rootfs is incorrectly labeled as system_u:object_r:root_t. I have temporarily worked around this by adding a restorecon on the rootfs at boot, but >>> >>> IIRC, when I worked on the Android integration we had to do the same >>> thing. Android comes with it's own init in the ramdisk, so we just >>> called restorecon on the parts of >>> ramdisk that were of interest within the init daemon codebase itself. >>> I don't think theirs anyway around that IIRC as the CPIO archive >>> doesn't support xattrs. >>> >>> I do recall seeing this patchset: >>> https://lwn.net/Articles/788922/ >>> >>> I didn't look much into it, but if that got merged, you might be able >>> to apply labels to ramdisk images. >>> >>>> since the rootfs is a ramdisk the changes do not survive a system reboot. >>>>> >>>>> I may be incorrect, but my understanding (assumption?) is that the labels would be applied when the policy is loaded at boot. So I cannot understand why the labels are always incorrect. >>>>> >>>> Filesystem labels are not applied when the policy is labeled. On >>>> filesystems that support xattrs, a fs_use_xattr rule is used to tell >>>> SELinux to use the label stored in the security.selinux xattrs, but >>>> the filesystem will still have to be labeled initially. If the fs does >>>> not support xattrs and every file can be labeled the same, then a >>>> genfscon rule can be used. >>>> >>>> I am not sure of your exact case, but you can find more information in >>>> the SELinux Notebook - See >>>> https://github.com/SELinuxProject/selinux-notebook >>>> >>>> Jim >>>> >>>>> >>>>> Thanks, >>>>> >>>>> Ian
