selinux-policy-3.5.13-46.fc10.noarch - slight hiccup!

[mike cloaked]

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.
-- 
View this message in context:
http://www.nabble.com/selinux-policy-3.5.13-46.fc10.noarch---slight-hiccu...
Sent from the Fedora List mailing list archive at Nabble.com.

[Daniel J Walsh]

-----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.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkmsU7kACgkQrlYvE4MpobN6lQCffrFK6jwoOzie8zepkchh5dDt
> WhgAn1F+TgmE+KKfSF8bcpEDADyvmzn6
> =4dD4
> -----END PGP SIGNATURE-----

[mike cloaked]

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!
-- 
View this message in context:
http://www.nabble.com/selinux-policy-3.5.13-46.fc10.noarch---slight-hiccu...
Sent from the Fedora List mailing list archive at Nabble.com.

[Rick Stevens]

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(a)nerd.com -
- AIM/Skype: therps2        ICQ: 22643734            Yahoo: origrps2 -
-                                                                    -
-  Time: Nature's way of keeping everything from happening at once.  -
----------------------------------------------------------------------

[Tony Molloy]

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



-- 

Dept. of Comp. Sci.
University of Limerick.

[mike cloaked]

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.
-- 
View this message in context:
http://www.nabble.com/selinux-policy-3.5.13-46.fc10.noarch---slight-hiccu...
Sent from the Fedora List mailing list archive at Nabble.com.

[mike cloaked]

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?
-- 
View this message in context:
http://www.nabble.com/selinux-policy-3.5.13-46.fc10.noarch---slight-hiccu...
Sent from the Fedora List mailing list archive at Nabble.com.

[Tony Molloy]

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. 


-- 

Dept. of Comp. Sci.
University of Limerick.

[mike cloaked]

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?
-- 
View this message in context:
http://www.nabble.com/selinux-policy-3.5.13-46.fc10.noarch---slight-hiccu...
Sent from the Fedora List mailing list archive at Nabble.com.

[Daniel J Walsh]

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


> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkmtQc4ACgkQrlYvE4MpobMcKACdGifRevbSSegtASaYvVrPFAVo
> nLQAoKzIyjAtMamo8vTBQYOVCcZVrQhZ
> =BNxC
> -----END PGP SIGNATURE-----

[mike cloaked]

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? 


-- 
View this message in context:
http://www.nabble.com/selinux-policy-3.5.13-46.fc10.noarch---slight-hiccu...
Sent from the Fedora List mailing list archive at Nabble.com.

[stan]

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. :-)