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.
