-----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-----
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
