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
On 2008-12-26, 20:13 GMT, Michal Jaegermann wrote:
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:
Isn't the answer that root should use central configuration in /etc/fetchmailrc anyway?
Matěj
On Fri, Dec 26, 2008 at 11:13:01PM +0100, Matej Cepl wrote:
On 2008-12-26, 20:13 GMT, Michal Jaegermann wrote:
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:
Isn't the answer that root should use central configuration in /etc/fetchmailrc anyway?
Answer to what? Misbehaviour of selinux? And what /etc/fetchmailrc is supposed to do have with this? It does not even exist and even if it would it would be totally irrelevant. It is not that root attempts here to grab some mail from some server.
Michal
On 2008-12-26, 22:30 GMT, Michal Jaegermann wrote:
Answer to what? Misbehaviour of selinux?
Well, root is not supposed to have its own emails anyway -- what do you need root fetch mail from? SELinux is not supposed to allow you anything you want to do.
It is not that root attempts here to grab some mail from some server.
It is not? Than what is it good for?
Matěj
-----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
/root is supposed to be labelled admin_home_t and most confined applications are not allowed to read/write anything in this directory. So procmail_t should not be allowed by default to read/write admin_home_t. If for some reason you want procmail to deliver files to root, you can add a custom module, as you seem to have indicated that you have. Why /root on the other machine is labeled user_home_t is a bug. Not sure why this is happening. Do you have an entry in your /etc/passwd with a UID > 500 with /root as a home dir? I have changed the tools that setup homedir labeling to not modify /root but I am not sure if this has gotten into F10 yet.
The reason we want to protect /root from confined domains, is to stop them from modifying /root/.bashrc or other files that the admin could be tricked into executing.
On Sat, Dec 27, 2008 at 06:43:58AM -0500, Daniel J Walsh wrote:
Michal Jaegermann wrote:
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.
...
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?
/root is supposed to be labelled admin_home_t and most confined applications are not allowed to read/write anything in this directory.
So procmail_t should not be allowed by default to read/write admin_home_t.
As a matter of fact it was not and it is still not doing that. Here procmail is used to reclassify and to send further mail, using less blunt means that an alias in /etc/aliases (and ensuring that any "outside" mail to root would land in /dev/null), and in this particular case it happens that none of these mails ends up in subdirectories of /root/. If and where procmail writes its temporary files, which apparently triggered some complaints, I really cannot tell without diving into sources. Besides even if root procmail would be storing some mails locally then who says that it would have to do that below /root/? Only this is not here nor there. I can work around this particular issue, although this would add extra complications and in more involved cases such hacks would be highly undesirable, but this was not the real question. This was just a specific example of what was triggered by an upgrade.
If for some reason you want procmail to deliver files to root, you can add a custom module, as you seem to have indicated that you have.
Yes, I did and the only effect was a slight change in complaints with 'allow2why' now playing dumb so now what I can do?
That still does not explain why I am seeing, for example, "system_u:system_r:logrotate_t:s0-s0:c0.c1023 is not allowed for system_u:system_r:logrotate_t:s0-s0:c0.c1023" with logwatch later producing mulitiple "NULL security context for user, but SELinux in permissive mode, continuing ()" and none of tools which I have giving me any clues why. It is possible that I do not know where to look but I only see in audit.log entries with "res=failed" immediately followed by "res=success" in the next line. What other catastrophies are still lurking there it remains to be seen.
The real question was why I am running an upgrade on one machine and I am ending up with a disaster and apparently the same action elsewhere has entirely different effects and if there is anything I can do about it. Only now you are implying that what works is really broken. That is nice to know.
Why /root on the other machine is labeled user_home_t is a bug. Not sure why this is happening. Do you have an entry in your /etc/passwd with a UID > 500 with /root as a home dir?
Of course not. The only entries in /etc/passwd with /root for a home directory look as follows:
root:x:0:0:root:/root:/bin/bash operator:x:11:0:operator:/root:/sbin/nologin
I have changed the tools that setup homedir labeling to not modify /root but I am not sure if this has gotten into F10 yet.
I only know that running 'restorecon -Rv /root' on either of these two "example" machine does not change anything even if labelling is different. OTOH in none of these cases an initial labelling was created "by hand".
The reason we want to protect /root from confined domains, is to stop them from modifying /root/.bashrc or other files that the admin could be tricked into executing.
The old principle says "if you will disallow dumb things then you will block smart things as well" and necessity of complicated workarounds open its own security holes - possibly more disastrous than what you were trying to guard against in the first place.
Michal
On Sat, Dec 27, 2008 at 10:23:13AM -0700, Michal Jaegermann wrote:
Why /root on the other machine is labeled user_home_t is a bug. Not sure why this is happening. Do you have an entry in your /etc/passwd with a UID > 500 with /root as a home dir?
Of course not. The only entries in /etc/passwd with /root for a home directory look as follows:
root:x:0:0:root:/root:/bin/bash operator:x:11:0:operator:/root:/sbin/nologin
Could you show us the result of
ls -Z /root
?
On Sat, Dec 27, 2008 at 07:43:40PM +0100, Jan Pazdziora wrote:
On Sat, Dec 27, 2008 at 10:23:13AM -0700, Michal Jaegermann wrote:
Why /root on the other machine is labeled user_home_t is a bug. Not sure why this is happening. Do you have an entry in your /etc/passwd with a UID > 500 with /root as a home dir?
Of course not. The only entries in /etc/passwd with /root for a home directory look as follows:
root:x:0:0:root:/root:/bin/bash operator:x:11:0:operator:/root:/sbin/nologin
Could you show us the result of
ls -Z /root
Where I am getting into troubles this shows
-rw------- root root system_u:object_r:admin_home_t:s0 anaconda-ks.cfg drwxr-xr-x root root system_u:object_r:admin_home_t:s0 Desktop drwxr-xr-x root root system_u:object_r:admin_home_t:s0 Documents drwxr-xr-x root root system_u:object_r:admin_home_t:s0 Download -rw-r--r-- root root system_u:object_r:admin_home_t:s0 install.log -rw-r--r-- root root system_u:object_r:admin_home_t:s0 install.log.syslog drwx------ root root system_u:object_r:admin_home_t:s0 Mail drwxr-xr-x root root system_u:object_r:admin_home_t:s0 Music drwxr-xr-x root root system_u:object_r:admin_home_t:s0 Pictures drwxr-xr-x root root system_u:object_r:admin_home_t:s0 Public -rw-r--r-- root root system_u:object_r:admin_home_t:s0 scsrun.log drwxr-xr-x root root system_u:object_r:admin_home_t:s0 Templates drwxr-xr-x root root system_u:object_r:admin_home_t:s0 tools -rw-r--r-- root root system_u:object_r:admin_home_t:s0 upgrade.log -rw-r--r-- root root system_u:object_r:admin_home_t:s0 upgrade.log.syslog drwxr-xr-x root root system_u:object_r:admin_home_t:s0 Videos
and /root itself ended up with the same system_u:object_r:admin_home_t:s0 label.
That other machine, a server which behaves after an upgrade, shows
-rw------- root root system_u:object_r:user_home_t anaconda-ks.cfg -rw-r--r-- root root system_u:object_r:user_home_t install.log -rw-r--r-- root root system_u:object_r:user_home_t install.log.syslog drwx------ root root system_u:object_r:user_home_t Mail lrwxrwxrwx root root system_u:object_r:user_home_t mail -> Mail lrwxrwxrwx root root system_u:object_r:user_home_t Maildir -> Mail -rw-r--r-- root root system_u:object_r:user_home_t upgrade.log -rw-r--r-- root root system_u:object_r:user_home_t upgrade.log.syslog
and system_u:object_r:user_home_dir_t on /root.
As I already mentioned in both cases 'restorecon -R /root' does not change anything.
In a sense I really more interested why after an upgrade I am consistently getting "Unable to get valid context for root" for the first of these two machines.
Michal
On Sat, Dec 27, 2008 at 04:26:13PM -0700, Michal Jaegermann wrote:
On Sat, Dec 27, 2008 at 07:43:40PM +0100, Jan Pazdziora wrote:
On Sat, Dec 27, 2008 at 10:23:13AM -0700, Michal Jaegermann wrote:
Why /root on the other machine is labeled user_home_t is a bug. Not sure why this is happening. Do you have an entry in your /etc/passwd with a UID > 500 with /root as a home dir?
Of course not. The only entries in /etc/passwd with /root for a home directory look as follows:
root:x:0:0:root:/root:/bin/bash operator:x:11:0:operator:/root:/sbin/nologin
Could you show us the result of
ls -Z /root
Where I am getting into troubles this shows
-rw------- root root system_u:object_r:admin_home_t:s0 anaconda-ks.cfg
This is correct. As Dan W. already explained, which is what the default policy sets and what it expects. You are welcome to modify the behaviour either via SELinux module, or maybe semanage fcontext would be enough.
[...]
That other machine, a server which behaves after an upgrade, shows
-rw------- root root system_u:object_r:user_home_t anaconda-ks.cfg
Could you run
ls -dZ /root
? (The thing I'm trying to verify is whether that /root is really a directory or a symlink pointing to somewhere else.)
On Sun, Dec 28, 2008 at 03:03:03PM +0100, Jan Pazdziora wrote:
On Sat, Dec 27, 2008 at 04:26:13PM -0700, Michal Jaegermann wrote:
Where I am getting into troubles this shows
-rw------- root root system_u:object_r:admin_home_t:s0 anaconda-ks.cfg
This is correct. As Dan W. already explained, which is what the default policy sets and what it expects. You are welcome to modify the behaviour either via SELinux module, or maybe semanage fcontext would be enough.
Sigh! Did you bother to read what was said before? I can modify until cows come home, and this already failed, but this was not the real question or questions.
Could you run
ls -dZ /root
Yes, I could, and I did and I already wrote that a label on this is system_u:object_r:admin_home_t:s0 and yes, /root is really a directory in all cases.
The real issue is that a "security" which starts to behave in an incomprehensible manner after a distro upgrade it totally untrustworthy hence much worse that such thing turned off. Do not get hang up on a particular illustration point. I tried to ask if anybody has to say anything on the true subject and so far nobody had to offer anything.
Michal
I got hit by something somewhat similar this morning on another machine. It was also recently updated from F8 to F10 and it had selinux turned on and in an enforcing mode. Up to now everything looked like it should but this morning the system got updates to
selinux-policy-3.5.13-38.fc10.noarch selinux-policy-targeted-3.5.13-38.fc10.noarch
After that every attempt to login was producing "Unable to get valid context for <whomever>" on every account this was tried (root only locally).
There are no log traces from failed attempts to log in locally but for similar tries over ssh one can find in /var/log/secure:
sshd[9945]: Accepted password for .... port 24443 ssh2 sshd[9945]: pam_unix(sshd:session): session opened for user .... by (uid=0) sshd[9945]: pam_selinux(sshd:session): Security context unconfined_u:system_r:logrotate_t:s0-s0:c0.c1023 is not allowed for unconfined_u:system_r:logrotate_t:s0-s0:c0.c1023 sshd[9945]: pam_selinux(sshd:session): Unable to get valid context for .... sshd[9945]: error: PAM: pam_open_session(): Authentication failure sshd[9945]: error: ssh_selinux_setup_pty: security_compute_relabel: Invalid argument
Looks familiar?
As this was in an enforcing mode then you just cannot login on a console or over a network.
Luckily just a reboot via a power switch "fixed" the situation and so far the whole setup seems to be in a working order. The only "sealert" message I can find in logs between selinux-policy updates and reboot is of that sort:
SELinux is preventing rpcbind (rpcbind_t) "search" to ./bin (bin_t). .... Source Context system_u:system_r:rpcbind_t:s0 Target Context system_u:object_r:bin_t:s0 Target Objects ./bin [ dir ] Source rpcbind Source Path /sbin/rpcbind ....
and this was "cured" by a reboot too.
Michal
-----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
On Mon, Dec 29, 2008 at 10:30:31AM -0500, Daniel J Walsh wrote:
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.
....
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?
Something rather weird for 'id -Z': system_u:system_r:system_crond_t:s0 The other machine after an upgrades reports 'root:unconfined_r:unconfined_t:SystemLow-SystemHigh' which looks like something saner.
# semanage login -l
Login Name SELinux User MLS/MCS Range
__default__ unconfined_u s0-s0:c0.c1023 root system_u s0-s0:c0.c1023 system_u system_u s0-s0:c0.c1023
which again is different than on another machine. Here we go:
Login Name SELinux User MLS/MCS Range
__default__ unconfined_u SystemLow-SystemHigh root root SystemLow-SystemHigh system_u system_u SystemLow-SystemHigh
and # semanage user -l
Labeling MLS/ MLS/ SELinux User Prefix MCS Level MCS Range SELinux Roles
guest_u guest s0 s0 guest_r root user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r staff_u user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r sysadm_u user s0 s0-s0:c0.c1023 sysadm_r system_u user s0 s0-s0:c0.c1023 system_r unconfined_u unconfined s0 s0-s0:c0.c1023 system_r unconfined_r user_u user s0 s0 user_r xguest_u xguest s0 s0 xguest_r
and this is on that second one:
Labeling MLS/ MLS/ SELinux User Prefix MCS Level MCS Range SELinux Roles
guest_u user s0 s0 guest_r root user s0 SystemLow-SystemHigh staff_r sysadm_r system_r unconfined_r staff_u user s0 SystemLow-SystemHigh staff_r sysadm_r system_r sysadm_u user s0 SystemLow-SystemHigh sysadm_r system_u user s0 SystemLow-SystemHigh system_r unconfined_u user s0 SystemLow-SystemHigh system_r unconfined_r user_u user s0 s0 user_r xguest_u user s0 s0 xguest_r
where at least "Labeling Prefixes" look suspicious for a change.
Finally what context is ssh running as.
# ps -eZ | grep ssh
system_u:system_r:system_crond_t:s0 3972 ? 00:00:00 sshd system_u:system_r:system_crond_t:s0 26371 ? 00:00:00 sshd
against
root:system_r:sshd_t:SystemLow-SystemHigh 10298 ? 00:00:00 sshd root:system_r:sshd_t:SystemLow-SystemHigh 28760 ? 00:00:00 sshd
where things appear to work as expected.
A label on /usr/sbin/sshd itself is system_u:object_r:sshd_exec_t:s0 in the first case and system_u:object_r:sshd_exec_t, without that trailing ":s0", in the second one.
All that fun simply as a result of running anaconda with an upgrade from F8 to F10; in both cases. I noted already that in the first case I had to do 'touch /.autorelabel' and reboot before I started to get anywhere and that was not needed in the second case.
Differences in a file system layout are are that for the first machine /, /boot, /usr, /usr/local, /var and /home are separate file systems while the second box has only /boot and / for everything (it is a specialized server).
This is not the first time when selinux starts to act "weird" for me on an installation after anaconda did its work. Only the other cases were starting from older distributions and this was for "scratch" installations in any case so the simplest wasy out was to dump results and run install again. In the current situation this is really not a good option and besides I would rather like to understand what is going on.
Michal
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Michal Jaegermann wrote:
On Mon, Dec 29, 2008 at 10:30:31AM -0500, Daniel J Walsh wrote:
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.
....
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?
Something rather weird for 'id -Z': system_u:system_r:system_crond_t:s0 The other machine after an upgrades reports 'root:unconfined_r:unconfined_t:SystemLow-SystemHigh' which looks like something saner.
# semanage login -l
Login Name SELinux User MLS/MCS Range
__default__ unconfined_u s0-s0:c0.c1023 root system_u s0-s0:c0.c1023 system_u system_u s0-s0:c0.c1023
which again is different than on another machine. Here we go:
Login Name SELinux User MLS/MCS Range
__default__ unconfined_u SystemLow-SystemHigh root root SystemLow-SystemHigh system_u system_u SystemLow-SystemHigh
and # semanage user -l
Labeling MLS/ MLS/SELinux User Prefix MCS Level MCS Range SELinux Roles
guest_u guest s0 s0 guest_r root user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r staff_u user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r sysadm_u user s0 s0-s0:c0.c1023 sysadm_r system_u user s0 s0-s0:c0.c1023 system_r unconfined_u unconfined s0 s0-s0:c0.c1023 system_r unconfined_r user_u user s0 s0 user_r xguest_u xguest s0 s0 xguest_r
and this is on that second one:
Labeling MLS/ MLS/SELinux User Prefix MCS Level MCS Range SELinux Roles
guest_u user s0 s0 guest_r root user s0 SystemLow-SystemHigh staff_r sysadm_r system_r unconfined_r staff_u user s0 SystemLow-SystemHigh staff_r sysadm_r system_r sysadm_u user s0 SystemLow-SystemHigh sysadm_r system_u user s0 SystemLow-SystemHigh system_r unconfined_u user s0 SystemLow-SystemHigh system_r unconfined_r user_u user s0 s0 user_r xguest_u user s0 s0 xguest_r
where at least "Labeling Prefixes" look suspicious for a change.
Finally what context is ssh running as.
# ps -eZ | grep ssh
system_u:system_r:system_crond_t:s0 3972 ? 00:00:00 sshd system_u:system_r:system_crond_t:s0 26371 ? 00:00:00 sshd
against
root:system_r:sshd_t:SystemLow-SystemHigh 10298 ? 00:00:00 sshd root:system_r:sshd_t:SystemLow-SystemHigh 28760 ? 00:00:00 sshd
where things appear to work as expected.
A label on /usr/sbin/sshd itself is system_u:object_r:sshd_exec_t:s0 in the first case and system_u:object_r:sshd_exec_t, without that trailing ":s0", in the second one.
All that fun simply as a result of running anaconda with an upgrade from F8 to F10; in both cases. I noted already that in the first case I had to do 'touch /.autorelabel' and reboot before I started to get anywhere and that was not needed in the second case.
Differences in a file system layout are are that for the first machine /, /boot, /usr, /usr/local, /var and /home are separate file systems while the second box has only /boot and / for everything (it is a specialized server).
This is not the first time when selinux starts to act "weird" for me on an installation after anaconda did its work. Only the other cases were starting from older distributions and this was for "scratch" installations in any case so the simplest wasy out was to dump results and run install again. In the current situation this is really not a good option and besides I would rather like to understand what is going on.
Michal
I think the problem is logging in as root is screwed up.
if you execute
# semanage login -m -s unconfined_u root This should cause root users to login in as unconfined_t automatically. The sshd running as system_crond_t? Does this happen on reboot? Or was this caused by logging in in permissive mode then restarting sshd?
On Sun, Jan 04, 2009 at 12:08:09PM -0500, Daniel J Walsh wrote:
Michal Jaegermann wrote:
Something rather weird for 'id -Z': system_u:system_r:system_crond_t:s0 The other machine after an upgrades reports 'root:unconfined_r:unconfined_t:SystemLow-SystemHigh' which looks like something saner.
# semanage login -l
Login Name SELinux User MLS/MCS Range
__default__ unconfined_u s0-s0:c0.c1023 root system_u s0-s0:c0.c1023 system_u system_u s0-s0:c0.c1023
I think the problem is logging in as root is screwed up.
Indeed. I had that impression for quite a while.
if you execute
# semanage login -m -s unconfined_u root This should cause root users to login in as unconfined_t automatically.
That indeed changes 'semanage login -l' output to
Login Name SELinux User MLS/MCS Range
__default__ unconfined_u s0-s0:c0.c1023 root unconfined_u s0-s0:c0.c1023 system_u system_u s0-s0:c0.c1023
but it does not help that much. I still get "Unable to get valid context for root" from a login and 'system_u:system_r:system_crond_t:s0' for 'id -Z'. BTW - that does not generate any audit messages; only "error: ssh_selinux_setup_pty: security_compute_relabel: Invalid argument", and related, in /var/log/secure.
The sshd running as system_crond_t?
I told you this is weird. All of that after an upgrade from F8 to F10. I really would like to know why as surely this is not a result of me trying hard to mess things up.
Does this happen on reboot?
That machine was rebooted a number of times and nothing changes. I cannot switch to 'enforcing' as the box is "remote" and most likely that would immediately cut me off. Before an upgrade this was 'targeted' and 'enforcing'. As I wrote before: after an upgrade I had to force relabelling on a reboot as otherwise most anything was only spitting on me.
BTW - I did some hacking and I do not see at this moment any "avc" type failure notificiations in /var/log/messages. Only right now the box is rather quiet. I am not sure what will happen when regular users will show up.
Michal
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Michal Jaegermann wrote:
On Sun, Jan 04, 2009 at 12:08:09PM -0500, Daniel J Walsh wrote:
Michal Jaegermann wrote:
Something rather weird for 'id -Z': system_u:system_r:system_crond_t:s0 The other machine after an upgrades reports 'root:unconfined_r:unconfined_t:SystemLow-SystemHigh' which looks like something saner.
# semanage login -l
Login Name SELinux User MLS/MCS Range
__default__ unconfined_u s0-s0:c0.c1023 root system_u s0-s0:c0.c1023 system_u system_u s0-s0:c0.c1023
I think the problem is logging in as root is screwed up.
Indeed. I had that impression for quite a while.
if you execute
# semanage login -m -s unconfined_u root This should cause root users to login in as unconfined_t automatically.
That indeed changes 'semanage login -l' output to
Login Name SELinux User MLS/MCS Range
__default__ unconfined_u s0-s0:c0.c1023 root unconfined_u s0-s0:c0.c1023 system_u system_u s0-s0:c0.c1023
but it does not help that much. I still get "Unable to get valid context for root" from a login and 'system_u:system_r:system_crond_t:s0' for 'id -Z'. BTW - that does not generate any audit messages; only "error: ssh_selinux_setup_pty: security_compute_relabel: Invalid argument", and related, in /var/log/secure.
The sshd running as system_crond_t?
I told you this is weird. All of that after an upgrade from F8 to F10. I really would like to know why as surely this is not a result of me trying hard to mess things up.
Does this happen on reboot?
That machine was rebooted a number of times and nothing changes. I cannot switch to 'enforcing' as the box is "remote" and most likely that would immediately cut me off. Before an upgrade this was 'targeted' and 'enforcing'. As I wrote before: after an upgrade I had to force relabelling on a reboot as otherwise most anything was only spitting on me.
BTW - I did some hacking and I do not see at this moment any "avc" type failure notificiations in /var/log/messages. Only right now the box is rather quiet. I am not sure what will happen when regular users will show up.
Michal
If you execute service sshd restart from the unconfined_t user does it still start as system_crond_t?
I actually just upgraded my Fathers machine from F8 to F10 and had a problem with the root account not being setup to login correctly. But I saw no problems with sshd?
On Sun, Jan 04, 2009 at 02:29:44PM -0500, Daniel J Walsh wrote:
If you execute service sshd restart from the unconfined_t user does it still start as system_crond_t?
# /etc/init.d/sshd restart Stopping sshd: [ OK ] Starting sshd: [ OK ] # ps -eZ | grep ssh system_u:system_r:system_crond_t:s0 23026 ? 00:00:00 sshd system_u:system_r:system_crond_t:s0 23074 ? 00:00:00 sshd
and the same after logging out and loging back in.
/usr/sbin/sshd has system_u:object_r:sshd_exec_t:s0 for its label.
I actually just upgraded my Fathers machine from F8 to F10 and had a problem with the root account not being setup to login correctly. But I saw no problems with sshd?
Other problems may show up yet. I do not know.
I do not think that this happens consistently across installations and so far I do not see any rhyme or reason. On another box you may not even notice that something is amiss. It is not hard to imagine that you _think_ that you have a selinux protection after an upgrade while in reality everything is totally out-of-whack.
The other machine which went through F8->F10 upgrade, and which I was using for comparisons, does not give me any grief but I am not sure if it really looks like it should.
Michal
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Michal Jaegermann wrote:
On Sun, Jan 04, 2009 at 02:29:44PM -0500, Daniel J Walsh wrote:
If you execute service sshd restart from the unconfined_t user does it still start as system_crond_t?
# /etc/init.d/sshd restart Stopping sshd: [ OK ] Starting sshd: [ OK ] # ps -eZ | grep ssh system_u:system_r:system_crond_t:s0 23026 ? 00:00:00 sshd system_u:system_r:system_crond_t:s0 23074 ? 00:00:00 sshd
and the same after logging out and loging back in.
/usr/sbin/sshd has system_u:object_r:sshd_exec_t:s0 for its label.
I actually just upgraded my Fathers machine from F8 to F10 and had a problem with the root account not being setup to login correctly. But I saw no problems with sshd?
Other problems may show up yet. I do not know.
I do not think that this happens consistently across installations and so far I do not see any rhyme or reason. On another box you may not even notice that something is amiss. It is not hard to imagine that you _think_ that you have a selinux protection after an upgrade while in reality everything is totally out-of-whack.
The other machine which went through F8->F10 upgrade, and which I was using for comparisons, does not give me any grief but I am not sure if it really looks like it should.
Michal
Can you execute
yum reinstall selinux-policy-targeted
and tell me if it gives you any errors?
On Tue, Jan 06, 2009 at 09:15:25AM -0500, Daniel J Walsh wrote:
Michal Jaegermann wrote:
I do not think that this happens consistently across installations and so far I do not see any rhyme or reason. On another box you may not even notice that something is amiss
Can you execute
yum reinstall selinux-policy-targeted
Sure ...
and tell me if it gives you any errors?
No errors or any other complaints at all.
Removed: selinux-policy-targeted.noarch 0:3.5.13-34.fc10
Installed: selinux-policy-targeted.noarch 0:3.5.13-34.fc10
Complete!
There is also no change in a behaviour AFAICS.
BTW - today I was moving another machine with an active selinux through the same F8->F10 procedure. So far it looks like that this one got away completely unscathed. Nothing was really done differently in this case. Does results depend on a sign of Zodiac?
Michal
Michal Jaegermann wrote:
On Tue, Jan 06, 2009 at 09:15:25AM -0500, Daniel J Walsh wrote:
Michal Jaegermann wrote:
I do not think that this happens consistently across installations and so far I do not see any rhyme or reason. On another box you may not even notice that something is amiss
Can you execute
yum reinstall selinux-policy-targeted
Sure ...
and tell me if it gives you any errors?
No errors or any other complaints at all.
Removed: selinux-policy-targeted.noarch 0:3.5.13-34.fc10
Installed: selinux-policy-targeted.noarch 0:3.5.13-34.fc10
Complete!
There is also no change in a behaviour AFAICS.
BTW - today I was moving another machine with an active selinux through the same F8->F10 procedure. So far it looks like that this one got away completely unscathed. Nothing was really done differently in this case. Does results depend on a sign of Zodiac?
I ran into a similar issue (F8 upgrade to F10). My method of fixing it:
(Boot up) # setenforce permissive # yum -y update selinux-policy-targeted (just in case) # touch /.autorelabel # reboot (wait for the relabel to take effect...could take a while)
Voila! ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks@nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - If at first you don't succeed, quit. No sense being a damned fool! - ----------------------------------------------------------------------
On Tue, Jan 06, 2009 at 06:27:36PM -0800, Rick Stevens wrote:
I ran into a similar issue (F8 upgrade to F10). My method of fixing it:
(Boot up) # setenforce permissive # yum -y update selinux-policy-targeted (just in case) # touch /.autorelabel # reboot
As I wrote at the opening of this thread I am way past this stage. Without this nothing practically worked. Now it "works", for some value of "works", but it is weird in places.
Voila!
At last not "Viola!". Thank you! :-)
Michal
Michal Jaegermann wrote:
On Tue, Jan 06, 2009 at 06:27:36PM -0800, Rick Stevens wrote:
I ran into a similar issue (F8 upgrade to F10). My method of fixing it:
(Boot up) # setenforce permissive # yum -y update selinux-policy-targeted (just in case) # touch /.autorelabel # reboot
As I wrote at the opening of this thread I am way past this stage. Without this nothing practically worked. Now it "works", for some value of "works", but it is weird in places.
Voila!
At last not "Viola!". Thank you! :-)
Michal
Boy ! The Selinux sure got a bad out of this deal. Why is it when something doesn't work Selinux always gets a bad Rap. Just because a Yellow star pops up that doesn't always mean that Selinux is preventing something from running.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Michal Jaegermann wrote:
On Sun, Jan 04, 2009 at 02:29:44PM -0500, Daniel J Walsh wrote:
If you execute service sshd restart from the unconfined_t user does it still start as system_crond_t?
# /etc/init.d/sshd restart Stopping sshd: [ OK ] Starting sshd: [ OK ] # ps -eZ | grep ssh system_u:system_r:system_crond_t:s0 23026 ? 00:00:00 sshd system_u:system_r:system_crond_t:s0 23074 ? 00:00:00 sshd
and the same after logging out and loging back in.
/usr/sbin/sshd has system_u:object_r:sshd_exec_t:s0 for its label.
I actually just upgraded my Fathers machine from F8 to F10 and had a problem with the root account not being setup to login correctly. But I saw no problems with sshd?
Other problems may show up yet. I do not know.
I do not think that this happens consistently across installations and so far I do not see any rhyme or reason. On another box you may not even notice that something is amiss. It is not hard to imagine that you _think_ that you have a selinux protection after an upgrade while in reality everything is totally out-of-whack.
The other machine which went through F8->F10 upgrade, and which I was using for comparisons, does not give me any grief but I am not sure if it really looks like it should.
Michal
Adding Steven Smalley for a fresh set of eyes.
On Wed, 2009-01-07 at 15:19 -0500, Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Michal Jaegermann wrote:
On Sun, Jan 04, 2009 at 02:29:44PM -0500, Daniel J Walsh wrote:
If you execute service sshd restart from the unconfined_t user does it still start as system_crond_t?
# /etc/init.d/sshd restart Stopping sshd: [ OK ] Starting sshd: [ OK ] # ps -eZ | grep ssh system_u:system_r:system_crond_t:s0 23026 ? 00:00:00 sshd system_u:system_r:system_crond_t:s0 23074 ? 00:00:00 sshd
and the same after logging out and loging back in.
/usr/sbin/sshd has system_u:object_r:sshd_exec_t:s0 for its label.
I actually just upgraded my Fathers machine from F8 to F10 and had a problem with the root account not being setup to login correctly. But I saw no problems with sshd?
Other problems may show up yet. I do not know.
I do not think that this happens consistently across installations and so far I do not see any rhyme or reason. On another box you may not even notice that something is amiss. It is not hard to imagine that you _think_ that you have a selinux protection after an upgrade while in reality everything is totally out-of-whack.
The other machine which went through F8->F10 upgrade, and which I was using for comparisons, does not give me any grief but I am not sure if it really looks like it should.
Michal
Adding Steven Smalley for a fresh set of eyes.
An earlier posting showed that his shell was running in system_crond_t, so it isn't surprising then that restarting sshd from that shell would leave it in system_crond_t (domain transitions are defined on the caller domain and the executable type, and there isn't any such transition defined from system cron jobs on executing sshd).
Then any subsequent login attempt via ssh would be similarly botched, because sshd is running in system_crond_t, and thus the starting domain isn't what the system expects and when we ask the system what user contexts are reachable from that starting domain, it gets rather puzzled.
Reboot the system, then login and look at pstree -Z output.
As to the original cause, I assume that this is due to: 1) The rather major changes that took place in the policy across these versions (in particular the merging of targeted and strict policies and the change to using unconfined_u and unconfined_r for unconfined processes), and 2) The (mis)use of semanage by the selinux-policy package to manage the seuser definitions rather than shipping one in the base policy package as originally intended and only using semanage for local customizations, thereby breaking the ability to cleanly upgrade (or at least making it rather fragile).
On Wed, Jan 07, 2009 at 03:41:55PM -0500, Stephen Smalley wrote:
Then any subsequent login attempt via ssh would be similarly botched, because sshd is running in system_crond_t, and thus the starting domain isn't what the system expects and when we ask the system what user contexts are reachable from that starting domain, it gets rather puzzled.
I was not that surprised with specific results, as they were consistent with what was showing up after all, as rather how I got there.
Reboot the system, then login and look at pstree -Z output.
This time it actually helped. Thanks! This is the first time the system got rebooted after selinux-policy-targeted got reinstalled yesterday. Maybe this made a difference? Before that rebooting did not seem to have any discernible effects.
I attach the current output from 'pstree -Z'; it looks to me as what I would roughly expect to see.`
As to the original cause, I assume that this is due to:
- The rather major changes that took place in the policy across these
versions ....
....
- The (mis)use of semanage by the selinux-policy package to manage the
seuser definitions ....
....
What for me is most disconcerting is that I went through the same exercise a few times and results were not consistent. Also I still would not know for sure how to repair a botched upgrade. It appears that this time I ended up with something which looks sane but why this reboot changed things while previous one were ineffective I am not sure.
Thanks, Michal
-
Daniel J Walsh -
Jan Pazdziora -
Jim -
Matej Cepl -
Michal Jaegermann -
Rick Stevens -
Stephen Smalley