On Mon, May 18, 2020 at 11:12:29AM +0200, Pino Toscano wrote:
On Tuesday, 5 May 2020 17:44:15 CEST Richard W.M. Jones wrote:
>
https://bugzilla.redhat.com/show_bug.cgi?id=1828952#c2
I think we need to do a different approach than this patch.
The biggest thing is that currently we check only SELINUXTYPE for the
actual policy, however we do not check SELINUX in case SELinux is in
enforcing mode at all.
IMHO we rather need to read /etc/selinux/<SELINUX> first:
- if enforcing, go ahead with the current relabeling: check SELINUXTYPE,
get the policy path, etc; if set like this, then most probably the
SELINUXTYPE points to a valid policy, otherwise the guest would not
even boot
- if permissive or disabled, do not perform any relabeling, including
touching /.autorelabel; this is because SELinux was disabled, so
attempting any relabeling might result in failures
Permissive and disabled seem to be different cases. If it's
permissive then SELinux is still "running" (but not enforcing
decisions).
I think the critical thing is actually what SELinux itself does to
update filesystem labels when selinux is set to either permissive or
disabled. I wasn't able to find any definitive information on this,
but testing by creating a new file in my home directory showed:
SELINUX=enforcing:
$ rm -f test
$ touch test
$ ls -lZ test
-rw-rw-r--. 1 rjones rjones unconfined_u:object_r:user_home_t:s0 0 Jun 24 09:48 test
permissive:
-rw-rw-r--. 1 rjones rjones unconfined_u:object_r:user_home_t:s0 0 Jun 24 09:49 test
disabled:
-rw-rw-r-- 1 rjones rjones ? 0 Jun 24 09:54 test
Anyway I think we at least need to treat enforcing and permissive the
same way.
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top