I wonder if this is my unique experience or this is widely observed.
So far, AFAICT, when installing a machine "from scratch", and while
keeping a layout as plain as possible, then selinux is rather
expected to work; at least decently enough. The picture becomes
entirely diferent when you are trying to upgrade a distro. What
results of such exercise will be I am unable to predict.
I have now such example recently moved from F8 to F10. It was
configured "targeted" and in the past it was behaving ok. Burned on
other occasions I set selinux to "permissive" before upgrading
distros with an intentions to restore "enforcing" later on. In
anaconda it is hard not to notice that an installation of
selinux-policy-targeted package takes a really long time. One would
think that this is because some checks are run or some relabeling
takes place or whatever. Only the end result was that after a
reboot a machine was mostly busy spitting all kind of complaints and
warnings. If not that "permissive" setting it most likely would
not boot at all. 'touch /.autorelabel' followed by a reboot and
relabelling took care of most of that stuff. But without the
machine really going into a service at least two "mysteries" remain
(and I fully expect more to show up later).
There is a requirement that a root needs to be able to login via
ssh on this machine using an authorized key (a remote root login
with a password is blocked). This works but I am getting every
time "Unable to get valid context for root" and in /var/log/secure:
"pam_selinux(sshd:session): Security context
system_u:system_r:logrotate_t:s0-s0:c0.c1023 is not allowed for
system_u:system_r:logrotate_t:s0-s0:c0.c1023".
Eh? What this is supposed to mean? There are no corresponding
'sealert' message I can find nor 'allow2why' comes with any reasons.
Another problem which hits immediately is that 'root' has
.procmailrc file and it is necessary there. Every mail to root
results in selinux complaints. Initially these were in a form:
SELinux is preventing the procmail from using potentially mislabeled
files (./_ZoC.lwQVJB.xxxxxx.yyyy.zzz).
and propositions to relabel these. A very good advice. :-)
This time 'allow2rules' had the following things to propose:
allow procmail_t admin_home_t:dir { write remove_name add_name };
allow procmail_t admin_home_t:file { write create unlink link };
I generated a corresponding module, and added it to a fray, and
that only changed a nature of complaints to:
SELinux is preventing the procmail from using potentially mislabeled
files (./.procmailrc).
The catch is that /root/.procmailrc has for a label
system_u:object_r:admin_home_t:s0 and 'restorecon -v' on it does not
change anything at all.
Of course I have no idea if there are policy problems, or troubles
are somewhere else, or everything really works as expected. A big
mystery.
To makes things even more interesting I have another machine, also
upgraded from F8 to F10 and configured, it would appear, in a
similar way, and none of symptoms described above shows there.
Only on that other box /root/.procmailrc is labeled with
system_u:object_r:user_home_t (do not ask me why!) and
system_u:object_r:user_home_dir_t shows on /root and running
there 'restorecon -vR /root' also does not change anything at all.
So apparently both are correct only one does not work and how and
why they aquired different labels is another of those puzzles.
Does selinux policies are applied at random?
Michal
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
