After upgrading from 3.6*, su and (presumably) agetty segfault with mls policy. Presumably ~arch is not testing this combination. One hopes that at least strict is tested for with CI. Booting in permissive shows denials for { open read search } tmp_t and { getattr setattr } user_tmp_t, as well as getty_t self : capability2 checkpoint_restore (policy was already up to date, though the problem emerged earlier with userland upgraded first, IIRC.) 3.6* does not segfault and logs in (sysadm_t) successfully. I should expect policy errors not to result in a segfault with 3.7*. Note that this user uses ephemeral VMs so disentangling the cause to a deterministic reproducer for a mere user is close to magic(!) so I would appreciate if devs could help reproduce.
Created attachment 900170 [details] Trimmed --info Note that this user tried compiling selinux userland update with default LDFLAGS (Wl,--as-needed) and -march=native -O2 -pipe help 'reduce'.
> Note that this user tried compiling selinux userland update with default LDFLAGS (Wl,--as-needed) and -march=native -O2 -pipe help 'reduce'. should read as > Note that this user tried compiling selinux userland update with default LDFLAGS (Wl,--as-needed) and -march=native -O2 -pipe to help 'reduce'. Sorry for the bugspam.
Does booting into permissive with userland 3.7 allow the system to function? Could you please provide the full AVCs for those denials that you are seeing? I'm going to set up a VM to test this and see if I can reproduce it, but my initial hunch is that this isn't specifically related to the MLS policy.
(In reply to Kenton Groombridge from comment #3) > Does booting into permissive with userland 3.7 allow the system to function? Yes, hence finding the denials. Note that instead of .private being created tmp_t, it is created as login_tmp_t, and restorecon is necessary (systemd_tmpfiles has mls restrictions on creating tmp_t so only solution there is to restorecon as sysadm_t). Hazily IIRC that is not the case in permissive boot. >Could you please provide the full AVCs for those denials that you are seeing? That would be very difficult at the moment. It requires redoing the changes, applying them to the base template and booting a ephemeral VM. Perhaps a stupid setup, but I hadn't considered these contingencies and it had worked up until now =/ I seriously had/have given up, hence the initial reporting and delay. > I'm going to set up a VM to test this and see if I can reproduce it, but my > initial hunch is that this isn't specifically related to the MLS policy. I would very much appreciate that. Note that bugzilla prompted me to enter an email address after entering the previous one, so I had to make another account. Sorry--I can only speculate that it's due to the '+'.
