DevHeads.net

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

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"

Comments

Re: As we develop SELinux we are adding new labels to homedir co

By Lennart Poettering at 06/01/2012 - 06:14

Heya,

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

Re: As we develop SELinux we are adding new labels to homedir co

By Bill Nottingham at 06/01/2012 - 16:12

Lennart Poettering (<a href="mailto: ... at 0pointer dot de"> ... at 0pointer dot de</a>) said:
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

Re: As we develop SELinux we are adding new labels to homedir co

By Daniel J Walsh at 06/01/2012 - 09:13

On 06/01/2012 06:14 AM, Lennart Poettering wrote:
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.

Re: As we develop SELinux we are adding new labels to homedir co

By Lennart Poettering at 06/01/2012 - 09:36

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

Re: As we develop SELinux we are adding new labels to homedir co

By Bill Peck at 06/01/2012 - 08:10

On 06/01/2012 06:14 AM, Lennart Poettering wrote:
How does this affect home dirs which are served over nfs?

Re: As we develop SELinux we are adding new labels to homedir co

By Daniel J Walsh at 06/01/2012 - 09:16

On 06/01/2012 08:10 AM, Bill Peck wrote:

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

Re: As we develop SELinux we are adding new labels to homedir co

By Miloslav =?UTF-... at 05/31/2012 - 16:06

On Thu, May 31, 2012 at 9:44 PM, Daniel J Walsh < ... at redhat dot com> wrote:
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

Re: As we develop SELinux we are adding new labels to homedir co

By =?ISO-8859-2?Q?... at 05/31/2012 - 16:02

On 31.5.2012 21:44, Daniel J Walsh wrote:
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