On Jul 7, 2016 09:50, "Jason Zaman" <jason@xxxxxxxxxxxxx> wrote:
>
> On Thu, Jul 07, 2016 at 08:43:45AM -0400, William Roberts wrote:
> > On Jul 7, 2016 08:40, "Sven Vermeulen" <sven.j.vermeulen@xxxxxxxxx> wrote:
> > >
> > > 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).
> >
> > Android uses a readonly ramdisk so even if it was remounted and written to,
> > the file would be gone on reboot. However, some newer Android stuff is
> > moving to an ext4 root filesystem. I'm a bit leary of this change as well,
> > although in Android if you write to the rootfs we've likely already lost,
> > best not to be adding functionality that could be used against us.
>
> Alternatively, if someone edits the boot image to have .autorelabel it
> will always come back. I definitely agree with not adding functionality
True, I didn't even think about that case.
> that can be used against us. Currently a user has to check
> /etc/selinux/config and the kernel commandline, adding more ways means
> more things the user can miss.
>
> Doesn't Android set the labels on the /system disk image during build?
Yes that is correct.
> Maybe virt-builder can copy that? This would also speed up initial
> deployment of new images.
>
> What steps are required during a default install in RHEL? does an
> install from a livecd without virt-builder also have this relabelling
> problem?
>
> One way I can think of is have a transition from kernel_t (or whatever
> the context would be on a completely unlabelled system) to a domain with
> perms to relabel everything. Since the labels would be missing pid1
> would have to runcon -t autorelabel_t ... but it seems the safer road
> than making absolutely everything permissive.
>
> Alternatively, is there a reason /etc/selinux/config shouldn't be set to
> permissive by default in the image? What do we gain with this extra way?
> If the user is going to autorelabel after install, they are already
> probably setting permissive in the config before they reboot too.
>
> -- Jason
>
> > > 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.
>
> > _______________________________________________
> > 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.
