I have just updated some f10 boxes a few minutes ago. On logging on again after rebooting to the new kernel this evening, the main user directories have had their contexts changed to usr_t so I presume some kind of relabelling has been done - but not correctly! After restorecon -vR /home/user the contexts have mostly reverted to where they should be - I initially noticed because ssh suddenly started demanding a passphrase when it should not need one - and then I noted avc denials.....
This is for selinux-policy-3.5.13-46.fc10.noarch and the related targeted policy.
I have tested on several systems and so far all is well after doing restorecon -vR /home as root to fix all user areas in one go. Any one user can fix their own user area by doing restorecon -vR /home/user I presume that this will lose any chcon changes - but any contexts that were saved as a rule using semanage fcontext presumably should be restored - though I have not had time to explore all directories yet.
This update was pushed to stable today so presumably it will take a while to sync to all mirrors.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Mike Cloaked wrote:
I have just updated some f10 boxes a few minutes ago. On logging on again after rebooting to the new kernel this evening, the main user directories have had their contexts changed to usr_t so I presume some kind of relabelling has been done - but not correctly! After restorecon -vR /home/user the contexts have mostly reverted to where they should be - I initially noticed because ssh suddenly started demanding a passphrase when it should not need one - and then I noted avc denials.....
This is for selinux-policy-3.5.13-46.fc10.noarch and the related targeted policy.
I have tested on several systems and so far all is well after doing restorecon -vR /home as root to fix all user areas in one go. Any one user can fix their own user area by doing restorecon -vR /home/user I presume that this will lose any chcon changes - but any contexts that were saved as a rule using semanage fcontext presumably should be restored - though I have not had time to explore all directories yet.
This update was pushed to stable today so presumably it will take a while to sync to all mirrors.
This is very strange, I have no idea why SELinux update would do this, and suspect that something else might have gone wrong. Were there other packages in the update?
I will update my F10 and see what is going on.
Could be someone is doing a chcon -t usr_t in a post install script?
selinux-policy should only be doing the equivalent of a restorecon -vR in its post install. Actually executes fixfiles "fixfiles -C ${FILE_CONTEXT}.pre restore"
Which figures out what was different between the old file context and the new and runs restorecon on them.
Daniel J Walsh wrote:
This is very strange, I have no idea why SELinux update would do this, and suspect that something else might have gone wrong. Were there other packages in the update?
I will update my F10 and see what is going on.
Could be someone is doing a chcon -t usr_t in a post install script?
I don't know but during the yum update the selinux-policy update produced a whole string of "*" chars on the terminal window during the update of that package (instead of the hashes between [] ), and there are lines in the /var/log/messages file afterwards with: Mar 2 19:49:25 home1 yum: Updated: selinux-policy-3.5.13-46.fc10.noarch Mar 2 19:49:49 home1 dbus: avc: received policyload notice (seqno=2) Mar 2 19:49:49 home1 dbus: avc: received policyload notice (seqno=2)
Maybe that is relevant - but I guess you will probe what is going on on your system. I also noticed that on some boxes only directories below /home were altered and on others /home itself was changed... very odd and a little un-nerving!
Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Mike Cloaked wrote:
I have just updated some f10 boxes a few minutes ago. On logging on again after rebooting to the new kernel this evening, the main user directories have had their contexts changed to usr_t so I presume some kind of relabelling has been done - but not correctly! After restorecon -vR /home/user the contexts have mostly reverted to where they should be - I initially noticed because ssh suddenly started demanding a passphrase when it should not need one - and then I noted avc denials.....
This is for selinux-policy-3.5.13-46.fc10.noarch and the related targeted policy.
I have tested on several systems and so far all is well after doing restorecon -vR /home as root to fix all user areas in one go. Any one user can fix their own user area by doing restorecon -vR /home/user I presume that this will lose any chcon changes - but any contexts that were saved as a rule using semanage fcontext presumably should be restored - though I have not had time to explore all directories yet.
This update was pushed to stable today so presumably it will take a while to sync to all mirrors.
This is very strange, I have no idea why SELinux update would do this, and suspect that something else might have gone wrong. Were there other packages in the update?
I will update my F10 and see what is going on.
Could be someone is doing a chcon -t usr_t in a post install script?
selinux-policy should only be doing the equivalent of a restorecon -vR in its post install. Actually executes fixfiles "fixfiles -C ${FILE_CONTEXT}.pre restore"
Which figures out what was different between the old file context and the new and runs restorecon on them.
Yes, but if the new context list contains an incorrect setting (usr_t instead of user_home_dir_t), then restorecon is going to set the usr_t context. After all, restorecon doesn't have that stuff compiled in, it reads it from the control file.
That being said, I've got an "exclude=selinux-policy-targeted*" in my yum configs until this is fixed. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks@nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Time: Nature's way of keeping everything from happening at once. - ----------------------------------------------------------------------
On Monday 02 March 2009 21:46:34 Daniel J Walsh wrote:
Mike Cloaked wrote:
I have just updated some f10 boxes a few minutes ago. On logging on again after rebooting to the new kernel this evening, the main user directories have had their contexts changed to usr_t so I presume some kind of relabelling has been done - but not correctly! After restorecon -vR /home/user the contexts have mostly reverted to where they should be - I initially noticed because ssh suddenly started demanding a passphrase when it should not need one - and then I noted avc denials.....
This is for selinux-policy-3.5.13-46.fc10.noarch and the related targeted policy.
I have tested on several systems and so far all is well after doing restorecon -vR /home as root to fix all user areas in one go. Any one user can fix their own user area by doing restorecon -vR /home/user I presume that this will lose any chcon changes - but any contexts that were saved as a rule using semanage fcontext presumably should be restored - though I have not had time to explore all directories yet.
This update was pushed to stable today so presumably it will take a while to sync to all mirrors.
This is very strange, I have no idea why SELinux update would do this, and suspect that something else might have gone wrong. Were there other packages in the update?
I will update my F10 and see what is going on.
Could be someone is doing a chcon -t usr_t in a post install script?
selinux-policy should only be doing the equivalent of a restorecon -vR in its post install. Actually executes fixfiles "fixfiles -C ${FILE_CONTEXT}.pre restore"
Which figures out what was different between the old file context and the new and runs restorecon on them.
I have to agree with Daniel here. I've just done an upgrade and rebooted without any problems.
[molloyt@nogs ~]$ rpm -qa --last | grep selinux selinux-policy-targeted-3.5.13-46.fc10 Tue Mar 3 08:13:10 2009 selinux-policy-3.5.13-46.fc10 Tue Mar 3 08:12:51 2009
Regards,
Tony
Tony Molloy wrote:
I have to agree with Daniel here. I've just done an upgrade and rebooted without any problems.
[molloyt@nogs ~]$ rpm -qa --last | grep selinux selinux-policy-targeted-3.5.13-46.fc10 Tue Mar 3 08:13:10 2009 selinux-policy-3.5.13-46.fc10 Tue Mar 3 08:12:51 2009
There are other problems now and it seems to depend on the setup on each machine - on one machine I am now getting an avc denial with:
"Summary SELinux is preventing procmail (procmail_t) "write" to ./tmp (usr_t). Detailed Description SELinux denied access requested by procmail. It is not expected that this access is required by procmail and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for ./tmp, restorecon -v './tmp' If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report against this package. Additional Information Source Context: system_u:system_r:procmail_t:s0 Target Context: system_u:object_r:usr_t:s0 Target Objects: ./tmp [ dir ] Source: procmail Source Path: /usr/bin/procmail"
I have rebooted and I have restorecon -vR /home as user - and of course this refers to ./tmp which is not in my home area so there is somewhere else that there is a wrongly set tmp directory now - and I can't find it!
This is not good - really not good.
Mike Cloaked wrote:
"Summary SELinux is preventing procmail (procmail_t) "write" to ./tmp (usr_t). Detailed Description SELinux denied access requested by procmail. It is not expected that this access is required by procmail and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for ./tmp, restorecon -v './tmp' If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report against this package. Additional Information Source Context: system_u:system_r:procmail_t:s0 Target Context: system_u:object_r:usr_t:s0 Target Objects: ./tmp [ dir ] Source: procmail Source Path: /usr/bin/procmail"
I have rebooted and I have restorecon -vR /home as user - and of course this refers to ./tmp which is not in my home area so there is somewhere else that there is a wrongly set tmp directory now - and I can't find it!
This is not good - really not good.
Seems that /var/spool/mail (which is bind mounted) had its contexts messed up - and restorecon -vR /var/spool/mail seems to have fixed this issue.
In fact I wonder now if bind mounted directories are where the problem is being seen? In my case I have bind mounted user areas and bind mounted mail spools... perhaps if you don't have any bind mounts you don't see a problem?
On Tuesday 03 March 2009 09:46:19 Mike Cloaked wrote:
Mike Cloaked wrote:
"Summary SELinux is preventing procmail (procmail_t) "write" to ./tmp (usr_t). Detailed Description SELinux denied access requested by procmail. It is not expected that this access is required by procmail and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for ./tmp, restorecon -v './tmp' If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report against this package. Additional Information Source Context: system_u:system_r:procmail_t:s0 Target Context: system_u:object_r:usr_t:s0 Target Objects: ./tmp [ dir ] Source: procmail Source Path: /usr/bin/procmail"
I have rebooted and I have restorecon -vR /home as user - and of course this refers to ./tmp which is not in my home area so there is somewhere else that there is a wrongly set tmp directory now - and I can't find it!
This is not good - really not good.
Seems that /var/spool/mail (which is bind mounted) had its contexts messed up - and restorecon -vR /var/spool/mail seems to have fixed this issue.
In fact I wonder now if bind mounted directories are where the problem is being seen? In my case I have bind mounted user areas and bind mounted mail spools... perhaps if you don't have any bind mounts you don't see a problem? --
Mike,
That could be it. I don't have any bind mounted directories.
regards,
Tony
View this message in context: http://www.nabble.com/selinux-policy-3.5.13-46.fc10.noarch---slight-hiccup% 21-tp22296524p22305447.html Sent from the Fedora List mailing list archive at Nabble.com.
Daniel J Walsh wrote:
This is very strange, I have no idea why SELinux update would do this, and suspect that something else might have gone wrong. Were there other packages in the update?
I will update my F10 and see what is going on.
Could be someone is doing a chcon -t usr_t in a post install script?
selinux-policy should only be doing the equivalent of a restorecon -vR in its post install. Actually executes fixfiles "fixfiles -C ${FILE_CONTEXT}.pre restore"
Which figures out what was different between the old file context and the new and runs restorecon on them.
Dan, I had a problem this morning on another machine where there is a bind mounted /var/spool/mail directory (restorecon -vR /var/spool/mail seems to have fixed it). In all the cases where the user contexts had a problem were machines with bind mounted /home areas. I wonder if this could be the common factor?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Mike Cloaked wrote:
Daniel J Walsh wrote:
This is very strange, I have no idea why SELinux update would do this, and suspect that something else might have gone wrong. Were there other packages in the update?
I will update my F10 and see what is going on.
Could be someone is doing a chcon -t usr_t in a post install script?
selinux-policy should only be doing the equivalent of a restorecon -vR in its post install. Actually executes fixfiles "fixfiles -C ${FILE_CONTEXT}.pre restore"
Which figures out what was different between the old file context and the new and runs restorecon on them.
Dan, I had a problem this morning on another machine where there is a bind mounted /var/spool/mail directory (restorecon -vR /var/spool/mail seems to have fixed it). In all the cases where the user contexts had a problem were machines with bind mounted /home areas. I wonder if this could be the common factor?
Yes if you bind mount a usr_t directory without telling the system about it, it could cause labeling problems.
For example, if you store your homedirs in /usr/myhome/dwalsh and bind mount this over /home/dwalsh. SELinux will label the directory usr_t since /usr/myhome/dwalsh defaults to a usr_t label. If you bind mount it over /home/dwalsh and run restorecon on /home/dwalsh it will label it properly. But depending on which directory have restorecon run on it you can get different results. Usually we only have small relabels that happen on policy upgrades, so it probably never hit this directory. But this update seems to have triggered a larger relabel something like
restorecon -R -v /usr
So the problem in SELinux is we do not have an easy way to say /usr/myhome == /home or /usr/myhome/dwalsh == /home/dwalsh
THis is on my todo list.
Sorry about the inconvience.
Daniel J Walsh wrote:
Yes if you bind mount a usr_t directory without telling the system about it, it could cause labeling problems.
For example, if you store your homedirs in /usr/myhome/dwalsh and bind mount this over /home/dwalsh. SELinux will label the directory usr_t since /usr/myhome/dwalsh defaults to a usr_t label. If you bind mount it over /home/dwalsh and run restorecon on /home/dwalsh it will label it properly. But depending on which directory have restorecon run on it you can get different results. Usually we only have small relabels that happen on policy upgrades, so it probably never hit this directory. But this update seems to have triggered a larger relabel something like
restorecon -R -v /usr
So the problem in SELinux is we do not have an easy way to say /usr/myhome == /home or /usr/myhome/dwalsh == /home/dwalsh
OK - in my case it is different on different machines - in one case for example I have /opt/Local/home bind mounted over /home as well as /opt/Local/mail bind mounted over /var/spool/mail - and this is very common for me so that the user areas and mail spools are not over-written during a clean install at the next version of Fedora - so this issue is of major importance to me.
On another system /home/opt is bind mounted over /opt as well as an analogous mail bind mount.
In all cases the contexts had been set for the directories soon after F10 was installed and the system was seeing these correct contexts in the bind mounted directories ever since until last night. The update then broke the contexts for these directories until a manual restorecon, which is how I understand your comments above?
Mike Cloaked wrote:
I have just updated some f10 boxes a few minutes ago. On logging on again after rebooting to the new kernel this evening, the main user directories have had their contexts changed to usr_t so I presume some kind of relabelling has been done - but not correctly! After restorecon -vR /home/user the contexts have mostly reverted to where they should be - I initially noticed because ssh suddenly started demanding a passphrase when it should not need one - and then I noted avc denials.....
This is for selinux-policy-3.5.13-46.fc10.noarch and the related targeted policy.
I have tested on several systems and so far all is well after doing restorecon -vR /home as root to fix all user areas in one go. Any one user can fix their own user area by doing restorecon -vR /home/user I presume that this will lose any chcon changes - but any contexts that were saved as a rule using semanage fcontext presumably should be restored - though I have not had time to explore all directories yet.
This update was pushed to stable today so presumably it will take a while to sync to all mirrors.
I've been running that policy since last Friday when I updated from updates-testing on F10 X86_64. There have been no problems (in fact it fixed many selinux problems on my system) and my home directory has the proper context without any intervention on my part. I don't know if it matters, but I am also running the updates-testing kernel. And I have been logged in since the reboot (I did do an autorelabel with the reboot). I don't want to shutdown all my nicely configured windows and applications, so I'm not going to check whether logging in and out changes things. :-)
-
Daniel J Walsh -
mike cloaked -
Rick Stevens -
stan -
Tony Molloy