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-targeted | Assignee: | Daniel Walsh <dwalsh> |
Status: | CLOSED RAWHIDE | QA Contact: | Ben Levenson <benl> |
Severity: | high | Docs Contact: | |
Priority: | low | ||
Version: | 8 | Keywords: | 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
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. 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)? 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 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. 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... 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. What directory/file is postfix_locat trying to read? I don't believe this was allowed prior to the change? 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 Everyhthing but spamassassin should probably be changed. 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? 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? 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 |