Bug 426359

Summary: After update to selinux-policy-targeted-3.0.8-68.fc8 all home directory files given unconfined policy
Product: [Fedora] Fedora Reporter: Need Real Name <bugzilla>
Component: selinux-policy-targetedAssignee: Daniel Walsh <dwalsh>
Status: CLOSED RAWHIDE QA Contact: Ben Levenson <benl>
Severity: high Docs Contact:
Priority: low    
Version: 8Keywords: Reopened
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-01-16 20:59:23 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Need Real Name 2007-12-20 14:22:00 UTC
Description of problem:
Just yum updated to version 3.0.8-68.fc8.
Running "fixfiles check /home" I noticed that all files in the home directory
now have a target policy of "unconfined_u:object_r:unconfined_xxxx_t" where xxxx
is from whatever the original policy was.

Comment 1 Daniel Walsh 2007-12-21 07:57:30 UTC
Yes homedirs for uncofined users in Fedora 8 now default to unconfined_home_t
and friends.  user_home_t will still work.

In Fedora 9 we are removing the distinction on homedirs.  So all homedirs will
be labeled user_****_t.

In Fedora 8 guest is guest_****t, unconfined_t is uncofined_****_t etc.

We did not force a relabel so unconfined_t will work fine with a user_home_t or
an unconfined_home_t.

Comment 2 Need Real Name 2007-12-21 08:19:55 UTC
I'm not sure I understand.
Did this change just occur during the last policy update?

Because with selinux-policy-targeted-3.0.8-64.fc8
> matchpathcon ~
/home/me  system_u:object_r:user_home_dir_t:s0
while with selinux-policy-targeted-3.0.8-68.fc8
> matchpathcon ~
/home/me  unconfined_u:object_r:unconfined_home_dir_t:s0

I guess if the change has truly no impact then it doesn't matter that much but
still it seems like a pretty significant change to occur between minor policy
releases particularly since it affects just about every file in /home.

Is there anywhere this change is documented (along with the implications of the
change)?

 

Comment 3 Need Real Name 2007-12-21 08:32:29 UTC
Also, I'm not sure what you mean by **** is that a synonym for unconfined or is
it a new policy name/convention.

Also, in the latest policy, even files in ~/.ssh would be relabeled from
user_u:object_r:user_home_ssh_t to unconfined_u:object_r:unconfined_home_t

while interestingly files in ~/.mozilla get reballed from
usr_u:object_r:user_mozilla_home_t to 
unconfined_u:object_r:unconfined_mozilla_home_t

So, I'm not sure that I understand what is going on and what is the rationale
for why some things get relabeled to unconfined_home_t while others get
relabelled to unconfined_xxxxx_home_t. Particularly, since I would think that
.ssh would be more security sensitive then .mozilla.

If this truly is the intended change, can you point me to some documentation and
explanation of what the changes mean and why.

Thanks

Comment 4 Daniel Walsh 2007-12-22 13:11:29 UTC
No I ment the **** to indicate multiple labels in the homedir.

unconfined_home_t
unconfined_gnome_home_t
unconfined_mozilla_home_t
unconfined_ssh_home_t

The default SELinux login user on a fresh install was unconfined_u.   But on
upgrades it was system_u.  So in the 68 update I fixed this since the system_u
login user was not working correctly in all cases.  So this was actually a
bugfix.  The actual type for system_u and unconfined_u was still unconfined_t so
most users would not see the change.

The difference in homedirs is also caused by upgrade versus fresh install.
We wanted to change the default types but did not want to force everyone to relabel.

The change should have little impact other then fixing some bugs when restarting
daemons.

Comment 5 Need Real Name 2007-12-23 04:07:40 UTC
OK. So I now understand that you are making the following changes in home
directories:
user_u            ->unconfined_u
user_****_home_t  ->unconfined_****_home_t

But why are you changing:
[~/.ssh] user_home_ssh_t -> unconfined_home_t
[~/.spamassassin and ~/.razor] user_spamassassin_home_t -> unconfined_home_t
[~/.mplayer] user_mplayer_home_t -> unconfined_home_t
[~/.pyzor] user_pyzor_home_t -> unconfined_home_t
[~/.screenrc] usr_screen_ro_home_t -> unconfined_home_t
[~/.ICEauthority] user_iceauth_home_t -> unconfined_home_t

While other special directories keep their special context such as:
unconfined_gnome_home_t, unconfined_mozilla_home_t.

Are these "special" context distinctions no longer important or is this a mistake?
Again, it would be helpful if you could point me (and others) to documentation
of such changes...


Please explain this inconsistency in relabeling...



Comment 6 Mark Knoop 2007-12-23 17:19:41 UTC
This does seem to have broken mail delivery (postfix/procmail) for me.
audit2allow recommends:

#============= postfix_local_t ==============
allow postfix_local_t unconfined_home_dir_t:dir search;
allow postfix_local_t unconfined_home_t:file { read getattr };

The access is denied and the mail is bounced. This seems like a bug to me.

Comment 7 Daniel Walsh 2007-12-31 15:10:06 UTC
What directory/file is postfix_locat trying to read?  I don't believe this was
allowed prior to the change?

Comment 8 Need Real Name 2007-12-31 15:47:32 UTC
Dan,
Can you just confirm for me that it was intentional to remove the special
contect labeling for:
.ssh
.spamassassin
.mplayer
.pyzor
.screenrc
.ICEAuthority
(along with probably some others that I don't use) from
/etc/selinux/targeted/context/files/file_contexts.homedir

Thanks
from /etc/selinux/contexts

Comment 9 Daniel Walsh 2008-01-03 16:20:45 UTC
Everyhthing but spamassassin should probably be changed.

Comment 10 Need Real Name 2008-01-04 16:30:09 UTC
OK - so does that mean that in subsequent policy releases the .spamassassin
labeling will be changed to unconfined_spamassassin_home_t analogous to the
original user_spamassassin_home_t labeling?


Comment 11 Daniel Walsh 2008-01-04 19:17:55 UTC
I am not sure.  This is much more clean in Rawhide, but I have to find a
compromise in F8.  I do not want unconfined processes running confined
spamassassin and spamc apps.  So policy is somewhat difficult to write to allow
selected directory access to a unconfined home dir.

What was postfix_local trying to access that caused the AVC?

Comment 12 Need Real Name 2008-01-15 19:54:28 UTC
Dan, it seems that the person who reported the postfix_local is not on the bug c
list so he may not be reading this thread.

As the original reporter, I am not having any problems per-se but just
originally started this thread because I noticed these changes to the default
home directory labeling and wasn't sure why or even whether the changes were
intended.

I now understand that you indeed intentionally were eliminating some of the
special labeling in the home directory and I personally am fine with that so far
since I haven't seen any ill effects from it. Also, I look forward to F9 to see
it all more logically cleaned up :)

Thanks