On Wed, Jul 6, 2016 at 2:12 PM, Richard W.M. Jones <rjones@xxxxxxxxxx> wrote: >> > The autorelabel feature has been broken in Fedora for a while. >> > virt-builder relies on this feature to enable SELinux in guests since >> > we are unable to set filesystem labels when generating the image. So >> > it comes down to me to try to fix this. There was a discussion on the >> > Fedora development list which explains the background and the reasons >> > why autorelabel is broken: >> > >> > http://thread.gmane.org/gmane.linux.redhat.fedora.devel/220453 >> > >> > The plan to fix autorelabel (also formulated in the above thread) is >> > in two parts: >> > >> > (1) [This patch] If the autorelabel condition is detected when loading >> > policy very early during boot, we set SELinux to permissive mode >> > (overriding the contents of /etc/selinux/config and the command line). >> >> Can't you just set enforcing=0 on the kernel commandline for the first >> boot? > > For virt-builder, no. We create automated images that must > boot themselves without manual intervention. > > However even ignoring my use case, I don't think it's a good idea > anyway. If /.autorelabel is set, then the labels on the filesystem > are known to be wrong. You shouldn't be making enforcement decisions > based on labels which you know are wrong. I agree with the sentiment, but not with its execution. You can't guarantee that there is a systemd generator or other process in place that will pick this situation up, run the setfiles (or equivalent) service, remove the touch file and reboot. If you could, then that would be awesome. Let's say there is a platform that does not support /.autorelabel (not sure how SEAndroid works, but on Gentoo we don't look at that file). This patch would place the system in permissive mode, but just continue regardless. >> This patch sounds a bit dangerous. If anyone can touch /.autorelabel >> later on the machine will be in permissive mode on next reboot. > > If someone can create files in / then I suspect you've got other > problems. In any case it will then immediately jump to the generator > and relabel in a (very) minimal environment and reboot. After this > second boot it'll be back to enforcing (or whatever is requested by > /etc/selinux/config). SELinux is quite capable of allowing people to create files in / while still not being able to do much else on the system. And the generator step is only on a set of platforms, not all of those supporting SELinux. Wouldn't it be possible to reverse the logic? Introduce a "checkautorelabel" kernel/boot option, and if that option is set, then activate this logic? That way, other platforms beyond Fedora can happily continue regardless, and you can by default enable the checkautorelabel boot option. Wkr, Sven Vermeulen _______________________________________________ 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.
