On 08/13/2015 06:23 AM, Stephen Smalley wrote: >> >> Ok, figured this one out mostly, I think. Thanks to manpage >> setfiles_selinux, I first had to set setfiles_mac_t to permissive with: >> >> semanage permissive -a setfiles_mac_t > That suggests that setfiles_mac_t policy needs to be augmented with > further allow rules; you can tell which ones based on ausearch -m AVC > -se setfiles_mac_t > Ok. so on Fedora 21, (using selinux-policy-targeted-3.13.1-105.20.fc21.noarch), it looks like I need this: # ausearch -m AVC -se setfiles_mac_t | audit2allow #============= setfiles_mac_t ============== allow setfiles_mac_t bin_t:file entrypoint; >> Then, I ran the setfiles commands under runcon as: >> >> runcon -t setfiles_mac_t -- chroot /mnt /sbin/setfiles -v -F -e /proc -e >> /sys -e /dev -e /selinux >> /etc/selinux/targeted/contexts/files/file_contexts / >> >> This fixes the previous "invalid argument" errors from setfiles. > I think those errors reflect a bug/gap in setfiles. Usually setfiles > validates and canonicalizes the contexts in file_contexts by writing > them to /sys/fs/selinux/context (a pseudo file) and reading back the > result. This will fail if selinuxfs is mounted in your chroot and your > host policy doesn't define the context. If selinuxfs is not mounted in > your chroot, then this will just create a regular file under > /sys/fs/selinux/context containing the context and read it back again, > so it will "pass". I'm guessing that it was failing in enforcing mode > because it wasn't allowed to create files under /sys/fs/selinux in the > chroot. I think we need a change to setfiles (e.g. a new option) to > fully disable this validation/canonicalization. That would seem useful in my use-case. > >> this process, there are still 2 labels that are wrong: >> >> [root@localhost ~]# restorecon -v -n -r / >> restorecon reset / context system_u:runcon -t setfiles_mac_t -- getfattr -n security.selinux /mnt/rootobject_r:mnt_t:s0->system_u:object_r:root_t:s0 >> restorecon reset /.autofsck context system_u:object_r:mnt_t:s0->system_u:object_r:etc_runtime_t:s0 >> >> I think the /.autofsck is getting created during boot, and maybe just >> inheriting from /. So, the question is why is / (root) still labeled as >> mnt_t instead of root_t ? When the system is still mounted under >> /mnt/test, /mnt/test (where / of the system is mounted) is correctly >> labeled as root_t, but this seems to change once unmounted and i boot >> the offline system? >> >> Any insights? > No, that seems very strange. How did you check the context of /mnt/root > before unmounting it? Try checking it this way: > runcon -t setfiles_mac_t -- getfattr -n security.selinux /mnt/root > > And likewise, once you unmount and reboot the offline system, try it as: > runcon -t setfiles_mac_t -- getfattr -n security.selinux / > This turned out to be an error due to an external process. The labeling of /mnt/root is in fact correct. We are building a system in /mnt/root, and when we use the recovery boot option from the install DVD, it appears to relabel / to mnt_t. We did this in order to setup grub in the bootsector. We noticed this because when we automated the grub-install w/o using the recovery DVD, / was labeled correctly as expected. Thanks for your help! -Bond _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
