On my Fedora 24 system, I see sesearch -A -s setfiles_mac_t -p entrypoint -c file -C Found 1 semantic av rules: allow setfiles_mac_t setfiles_exec_t : file { ioctl read getattr lock execute execute_no_trans entrypoint open } ; chcon -t setfiles_exec_t to the program would be better. On 08/17/2015 04:27 PM, Bond Masuda wrote: > > 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. > > _______________________________________________ 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.