On 07/13/2016 03:31 PM, Richard W.M. Jones wrote: > On Tue, Jul 12, 2016 at 02:25:41PM -0400, Stephen Smalley wrote: >> On 07/12/2016 02:01 PM, Richard W.M. Jones wrote: >>> On Tue, Jul 12, 2016 at 01:22:55PM -0400, Stephen Smalley wrote: >>>> On 07/07/2016 04:56 PM, Richard W.M. Jones wrote: >>>>> On Thu, Jul 07, 2016 at 09:50:17PM +0800, Jason Zaman wrote: >>>>>> Doesn't Android set the labels on the /system disk image during build? >>>>>> Maybe virt-builder can copy that? This would also speed up initial >>>>>> deployment of new images. >>>>> >>>>> Well this is the real problem. Because the guest policy is a binary >>>>> blob, and because the binary blobs are not (necessarily) compatible >>>>> across kernel versions, we cannot just load the policy blob of the >>>>> guest into our kernel, so we cannot label guests properly. Sure be >>>>> nice if policy wasn't stored in this way. >>>> >>>> Just to clarify, it is not necessary to load the guest policy into the >>>> host kernel in order to set labels on the guest filesystem. SELinux >>>> long ago introduced support for setting foreign/unknown labels on files >>>> by processes with the appropriate permissions, and that mechanism was >>>> used by livecd creator IIRC - it was also intended for use by rpm for >>>> labeling files before the corresponding policy module was installed but >>>> they never took advantage of it. >>> >>> IME you cannot set any label unless SELinux is enabled in the >>> appliance kernel, but even assuming this is really possible, how do >>> you know what label should you set? Really we just want to do >>> "restorecon -R /" but that has proven to be impossible. >> >> Hmm...the kernel certainly supports setting labels as long as the >> filesystem xattr support is enabled, and setfiles used to work even if >> SELinux is disabled, but admittedly we don't test on SELinux-disabled >> very often. >> >> For SELinux-enabled, something like: >> 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 / >> has been reported to work in the past. The process needs CAP_MAC_ADMIN >> in its effective capability set and it needs to be in a domain that is >> allowed mac_admin by policy (hence the runcon -t setfiles_mac_t above). > > Thanks - can confirm this works even with SELinux disabled in the > appliance kernel. I think this is the approach we will take, and it > also means we don't need /.autorelabel to be fixed now. Hmm...I think we still want to fix autorelabel regardless, just hopefully either without the need to switch to permissive mode at all or a tighter binding between switching to permissive and triggering the relabeling and reboot sequence. In Android, there is a notion of a recursive restorecon on upgrades that is automatically triggered when the file_contexts configuration changes. That works by saving a hash of the file_contexts configuration(s) in an xattr on the top-level directory of the mount and checking whether it has changed. But in that case everything happens from the init process (based on init.rc configuration files), and SELinux is always enabled and enforcing in Android, so we don't have to deal with scenarios where the user has temporarily disabled SELinux and then re-enables it, and init has all the permissions it needs. The support for performing the recursive restorecon however is now available in libselinux, so it could be triggered directly by systemd. _______________________________________________ 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.
