As we develop SELinux we are adding new labels to homedir content

[Daniel J Walsh]

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

We have added file trans by name rules to policy to fix a lot of
files/directories being created with the correct label.

We have problems on Distribution updates (F16-F17) though, where there is a
files/directories in the homedir that are mislabeled.

We have "restorecond -u"  which we run in F15/F16 which examines the homedir
and fixes any files directories it finds mislabeled in ~.  If it finds a dir
which is mislabeled, it will relabel the directory and all of its children.
We have turned this tool off by default on the desktop in F17, because
filename transition rules are doing a pretty good job of maintaining the
labels in the homedir.  But this tool never did a great job of fixing
mislabeled subdirs, if the top level directory in the homedir was labeled
correctly.
You can enable this tool with /etc/xdg/autostart/restorecond.desktop

One possible fix to this would be to force a system relabel on everything on
upgrades, while this would fix the labels, it is considered to time consuming.
(restorecon -R -v / or touch /.autorelabel)

Another option would be to just relabel /home (# restorecon -R -v /home) at
upgrade time.  But this would also be time consuming. And would not catch the
cases where the homedir is not in /home.

A third option would be to run "restorecon -R -v $HOME" in background in an
profile script the first time you login on a new OS Version.  This would seem
to be the least time consuming, but could be subject to race conditions, you
hit the mislabeled file before the restorecon fixes it.  This would be better
then what we have now, in that everyone can hit the mislabeled file directory.

Final option would be to do nothing, which is what we are doing in F17, until
we get a bug reported and tell the user to run "restorecon -R -v /home"
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk/HyhEACgkQrlYvE4MpobPilwCgx8rn5Yu+jlOm/kzTWf/3oLlT
> 8jEAoKavA8sEghVkc2sxVhuZIYHBMSXB
> =wn44
> -----END PGP SIGNATURE-----

[Miroslav Suchý]

On 31.5.2012 21:44, Daniel J Walsh wrote:
>  A third option would be to run "restorecon -R -v $HOME" in
> background in an
>  profile script the first time you login on a new OS Version.  This would seem
>  to be the least time consuming, but could be subject to race conditions, you
>  hit the mislabeled file before the restorecon fixes it.  This would be better
>  then what we have now, in that everyone can hit the mislabeled file directory. 
I mostly prefer latency on my workstation/latency and waiting for 
relabel is PITA. I would rather risk reboot if I ever hit that race 
condition (chance is 0.0001%?).
But on (production) server I would not mind waiting for relabeling.

I would propose to relabel in background by default (honestly my mother 
does not care about SElinux) and if user knows and care - as sysadmin of 
server - he will flip some option in /etc/selinux/config just before 
reboot and relabeling will be done in foreground as is done today with 
/.autorelabel

Mirek

[Miloslav Trmač]

On Thu, May 31, 2012 at 9:44 PM, Daniel J Walsh <dwalsh(a)redhat.com&gt; wrote:
>  A third option would be to run "restorecon -R -v $HOME" in
> background in an
>  profile script the first time you login on a new OS Version.  This would seem
>  to be the least time consuming, but could be subject to race conditions, you
>  hit the mislabeled file before the restorecon fixes it.  This would be better
>  then what we have now, in that everyone can hit the mislabeled file directory. 
It would also turn labeling problems into heisenbugs that are
impossible to reproduce or diagnose, supporting the impression that
"SELinux breaks systems" and "it is difficult to understand SELinux".

Would it be possible to keep restorecond running on the systems
updated from older releases, and have it disabled by default on fresh
installs?  (If I understand correctly, this already affects F17, so it
is too late...)
    Mirek

[Lennart Poettering]

On Thu, 31.05.12 15:44, Daniel J Walsh (dwalsh(a)redhat.com) wrote:

Heya,

>  We have added file trans by name rules to policy to fix a lot of
>  files/directories being created with the correct label.
>  
>  We have problems on Distribution updates (F16-F17) though, where there is a
>  files/directories in the homedir that are mislabeled.
>  
>  We have "restorecond -u"  which we run in F15/F16 which examines the homedir
>  and fixes any files directories it finds mislabeled in ~.  If it finds a dir
>  which is mislabeled, it will relabel the directory and all of its children.
>  We have turned this tool off by default on the desktop in F17, because
>  filename transition rules are doing a pretty good job of maintaining the
>  labels in the homedir.  But this tool never did a great job of fixing
>  mislabeled subdirs, if the top level directory in the homedir was labeled
>  correctly.
>  You can enable this tool with /etc/xdg/autostart/restorecond.desktop
>  
>  One possible fix to this would be to force a system relabel on everything on
>  upgrades, while this would fix the labels, it is considered to time consuming.
>  (restorecon -R -v / or touch /.autorelabel)
>
>  Another option would be to just relabel /home (# restorecon -R -v /home) at
>  upgrade time.  But this would also be time consuming. And would not catch the
>  cases where the homedir is not in /home.  
I am strongly for this option. Allowing the user to login while the
relabel is still in progress (like it would with restorecond, right?)
sounds like a really bad idea... I mean, incorrect labels when used just
lead to more incorrect labels, no? And incorrect labels also result in
access errors? Both sound like something to avoid...

To me it appears that preupgrade should really take care of this on all
Fedora release updates.

If the relabelling is slow, maybe we can do something about that? Do you
know why it is slow? Is this more IO bound? Or is the label lookup slow
and this is CPU bound? If the latter it might be possible to parallelize
the relabelling?

(I wouldn't care too much about homedirs outside of /home. A not in the
release notes for such cases should suffice)

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Bill Peck]

On 06/01/2012 06:14 AM, Lennart Poettering wrote:
>  On Thu, 31.05.12 15:44, Daniel J Walsh (dwalsh(a)redhat.com) wrote:
>
>  Heya,
>
> > We have added file trans by name rules to policy to fix a lot of
> > files/directories being created with the correct label.
> >
> > We have problems on Distribution updates (F16-F17) though, where there is a
> > files/directories in the homedir that are mislabeled.
> >
> > We have "restorecond -u"  which we run in F15/F16 which examines the
> homedir
> > and fixes any files directories it finds mislabeled in ~.  If it finds a dir
> > which is mislabeled, it will relabel the directory and all of its children.
> > We have turned this tool off by default on the desktop in F17, because
> > filename transition rules are doing a pretty good job of maintaining the
> > labels in the homedir.  But this tool never did a great job of fixing
> > mislabeled subdirs, if the top level directory in the homedir was labeled
> > correctly.
> > You can enable this tool with /etc/xdg/autostart/restorecond.desktop
> >
> > One possible fix to this would be to force a system relabel on everything on
> > upgrades, while this would fix the labels, it is considered to time consuming.
> > (restorecon -R -v / or touch /.autorelabel)
> >
> > Another option would be to just relabel /home (# restorecon -R -v /home) at
> > upgrade time.  But this would also be time consuming. And would not catch the
> > cases where the homedir is not in /home.
>  I am strongly for this option. Allowing the user to login while the
>  relabel is still in progress (like it would with restorecond, right?)
>  sounds like a really bad idea... I mean, incorrect labels when used just
>  lead to more incorrect labels, no? And incorrect labels also result in
>  access errors? Both sound like something to avoid...
>
>  To me it appears that preupgrade should really take care of this on all
>  Fedora release updates.
>
>  If the relabelling is slow, maybe we can do something about that? Do you
>  know why it is slow? Is this more IO bound? Or is the label lookup slow
>  and this is CPU bound? If the latter it might be possible to parallelize
>  the relabelling?
>
>  (I wouldn't care too much about homedirs outside of /home. A not in the
>  release notes for such cases should suffice)
>
>  Lennart
>  
How does this affect home dirs which are served over nfs?

[Daniel J Walsh]

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

On 06/01/2012 08:10 AM, Bill Peck wrote:
>  On 06/01/2012 06:14 AM, Lennart Poettering wrote:
> > On Thu, 31.05.12 15:44, Daniel J Walsh (dwalsh(a)redhat.com) wrote:
> > 
> > Heya,
> > 
> >> We have added file trans by name rules to policy to fix a lot of 
> >> files/directories being created with the correct label.
> >> 
> >> We have problems on Distribution updates (F16-F17) though, where there
> >> is a files/directories in the homedir that are mislabeled.
> >> 
> >> We have "restorecond -u"  which we run in F15/F16 which examines the
> >> homedir and fixes any files directories it finds mislabeled in ~.  If
> >> it finds a dir which is mislabeled, it will relabel the directory and
> >> all of its children. We have turned this tool off by default on the
> >> desktop in F17, because filename transition rules are doing a pretty
> >> good job of maintaining the labels in the homedir.  But this tool never
> >> did a great job of fixing mislabeled subdirs, if the top level
> >> directory in the homedir was labeled correctly. You can enable this
> >> tool with /etc/xdg/autostart/restorecond.desktop
> >> 
> >> One possible fix to this would be to force a system relabel on
> >> everything on upgrades, while this would fix the labels, it is
> >> considered to time consuming. (restorecon -R -v / or touch
> >> /.autorelabel)
> >> 
> >> Another option would be to just relabel /home (# restorecon -R -v
> >> /home) at upgrade time.  But this would also be time consuming. And
> >> would not catch the cases where the homedir is not in /home.
> > I am strongly for this option. Allowing the user to login while the 
> > relabel is still in progress (like it would with restorecond, right?) 
> > sounds like a really bad idea... I mean, incorrect labels when used just 
> > lead to more incorrect labels, no? And incorrect labels also result in 
> > access errors? Both sound like something to avoid...
> > 
> > To me it appears that preupgrade should really take care of this on all 
> > Fedora release updates.
> > 
> > If the relabelling is slow, maybe we can do something about that? Do you 
> > know why it is slow? Is this more IO bound? Or is the label lookup slow 
> > and this is CPU bound? If the latter it might be possible to parallelize 
> > the relabelling?
> > 
> > (I wouldn't care too much about homedirs outside of /home. A not in the 
> > release notes for such cases should suffice)
> > 
> > Lennart
> > 
>  
>  How does this affect home dirs which are served over nfs? 

It would not, restorecon checks to see if the file system supports SELinux
labels, if not it exits immediately.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk/IwLkACgkQrlYvE4MpobNAAQCfS/CgjBpA/Lpa9Jq5PK836MAw
> i9EAn1woncYuNKpCP8XILq1FtK3Y+PEq
> =47g+
> -----END PGP SIGNATURE-----

[Daniel J Walsh]

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

On 06/01/2012 06:14 AM, Lennart Poettering wrote:
>  On Thu, 31.05.12 15:44, Daniel J Walsh (dwalsh(a)redhat.com) wrote:
>  
>  Heya,
>  
> > We have added file trans by name rules to policy to fix a lot of 
> > files/directories being created with the correct label.
> > 
> > We have problems on Distribution updates (F16-F17) though, where there is
> > a files/directories in the homedir that are mislabeled.
> > 
> > We have "restorecond -u"  which we run in F15/F16 which examines the
> > homedir and fixes any files directories it finds mislabeled in ~.  If it
> > finds a dir which is mislabeled, it will relabel the directory and all of
> > its children. We have turned this tool off by default on the desktop in
> > F17, because filename transition rules are doing a pretty good job of
> > maintaining the labels in the homedir.  But this tool never did a great
> > job of fixing mislabeled subdirs, if the top level directory in the
> > homedir was labeled correctly. You can enable this tool with
> > /etc/xdg/autostart/restorecond.desktop
> > 
> > One possible fix to this would be to force a system relabel on everything
> > on upgrades, while this would fix the labels, it is considered to time
> > consuming. (restorecon -R -v / or touch /.autorelabel)
> > 
> > Another option would be to just relabel /home (# restorecon -R -v /home)
> > at upgrade time.  But this would also be time consuming. And would not
> > catch the cases where the homedir is not in /home.
>  
>  I am strongly for this option. Allowing the user to login while the relabel
>  is still in progress (like it would with restorecond, right?) sounds like a
>  really bad idea... I mean, incorrect labels when used just lead to more
>  incorrect labels, no? And incorrect labels also result in access errors?
>  Both sound like something to avoid...
>  
>  To me it appears that preupgrade should really take care of this on all 
>  Fedora release updates.
>  
>  If the relabelling is slow, maybe we can do something about that? Do you 
>  know why it is slow? Is this more IO bound? Or is the label lookup slow and
>  this is CPU bound? If the latter it might be possible to parallelize the
>  relabelling?
>  
>  (I wouldn't care too much about homedirs outside of /home. A not in the 
>  release notes for such cases should suffice)
>  
>  Lennart
>   
Well it is slow in the same sense as find /home would be slow, restorecon is
using fts or ntfs to walk the file system and reads in the SELinux Context
(getxattr), asks SELinux what it should be labeled (matchpathcon), does a
compare, if they are different, does a setxattr on the inode.  Depends on the
number of inodes in the /home dir.

You could time it doing a restorecon -R -v /home right now, my system which
has piled up a ton of crap and exploded development pools takes nearly 2 minutes.

time restorecon -R  /home

real	1m42.677s
user	0m41.747s
sys	0m39.888s


If you had Huge file systems it could take a large amount of time.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk/IwAYACgkQrlYvE4MpobPrhwCgtn+VhZimc5uD6xHZoSqHwC/O
> +KYAoLM0Ahv5PkumbCxT1GBU1oAL2MI7
> =Qvnv
> -----END PGP SIGNATURE-----

[Lennart Poettering]

On Fri, 01.06.12 09:13, Daniel J Walsh (dwalsh(a)redhat.com) wrote:

>  > (I wouldn't care too much about homedirs outside of /home. A
> not in the 
>  > release notes for such cases should suffice)
>  > 
>  > Lennart
>  > 
>  
>  Well it is slow in the same sense as find /home would be slow, restorecon is
>  using fts or ntfs to walk the file system and reads in the SELinux Context
>  (getxattr), asks SELinux what it should be labeled (matchpathcon), does a
>  compare, if they are different, does a setxattr on the inode.  Depends on the
>  number of inodes in the /home dir.
>  
>  You could time it doing a restorecon -R -v /home right now, my system which
>  has piled up a ton of crap and exploded development pools takes nearly 2 minutes.
>  
>  time restorecon -R  /home
>  
>  real	1m42.677s
>  user	0m41.747s
>  sys	0m39.888s
>  
>  
>  If you had Huge file systems it could take a large amount of time. 
On my system here (with SSD) this appears to be CPU bound, not IO
bound. Hence optimizing this to be fully parallelized might be worth a
try?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Bill Nottingham]

Lennart Poettering (mzerqung(a)0pointer.de) said: 
>  > Another option would be to just relabel /home (# restorecon -R
> -v /home) at
>  > upgrade time.  But this would also be time consuming. And would not catch the
>  > cases where the homedir is not in /home. 
>  
>  I am strongly for this option. Allowing the user to login while the
>  relabel is still in progress (like it would with restorecond, right?)
>  sounds like a really bad idea... I mean, incorrect labels when used just
>  lead to more incorrect labels, no? And incorrect labels also result in
>  access errors? Both sound like something to avoid... 
I agree here as well. Given that even in our crazy Fedora world, we're only
doing upgrades at most every 6 months, an extra minute or 3 in the upgrade
process is just noise, it's not a dealbreaker.

Bill