selinux adventures/troubles

Daniel J Walsh dwalsh at redhat.com
Mon Dec 29 15:30:31 UTC 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michal Jaegermann wrote:
> 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
> 
Ok lets look at the log file.

  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".

When you log in in permissive mode what does 'id -Z' show?

What does

# semanage login -l
and
# semanage user -l

Finally what context is ssh running as.

# ps -eZ | grep ssh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAklY7RcACgkQrlYvE4MpobNUugCfeexMiZPbyYIgjSHeX6gSDVeU
2wkAmgMetyVDEYEPidAd5ispMYTnnJs4
=XUye
-----END PGP SIGNATURE-----




More information about the fedora-test-list mailing list