The various "disable selinux for service X" booleans have been removed in F7. This is a severe regression. While I like the public_content_t type quite a lot, it doesn't fully address the need that the disable flags served. For example, rsync is used internally for cross-machine backups and copies via the rsync server in many locations. For this type of use, it is necessary either (a) to disable rsync/selinux, or (b) to build a custom policy file. Problem with the latter is that in the backup scenario you really want the rsync server to ignore selinux restrictions entirely. I don't think that it is necessary to put the "disable" booleans back, but it would be extremely helpful to see an example policy module source file (a .te file) that illustrates how to adapt the targeted policy to achieve the same result for those who need it. In some sense this is a documentation problem. The documents describing how to build policy modules just aren't very good, and the extensive use of M4 in the distributed policies (which I recognize makes sense for these) makes them absolutely worthless as examples of how to do local policy modifications. Purely as a personal opinion, I think that removing the disable flags was a bad decision. The fact is that (1) selinux will *never* be perfectly stable, because it is always racing to catch up with the applications, and (2) there will always be sites whose requirements fall outside of the envisioned selinux design. In both cases, it is preferable to disable selinux selectively rather than entirely. In the former case the ability to disable selectively may make the difference between disrupted operations and non-disrupted operations. By removing these flags, the latest policy takes an "all or nothing" stance, which seems counterproductive.
To clarify: by "racing to catch up with the applications", I meant "... because the applications are moving". The release-day incompatibilities between selinux and xen are a great case in point. Much work was done to render selinux xen-friendly, and then somebody made a late decision to update xen prior to release, rendering xen+selinux broken again.
disable_trans was removed because they were causing as many problems as it was solving. For example. If you disable trans on syslog, you will generate avc messages in every application that uses it since the proper transitions will not happen. A much better and easier solution is to use audit2allow to generate custom policy to solve your immediate problem. So if you have a problem with a confined app, run the app in permissive mode to gether the avc messages grep CONFINED_T /var/log/audit/audit.log | audit2allow -M myCONFINED semodule -i myCONFINED.pp Now CONFINED should run, and you can report the AVC's to bugzilla. If you still want to disable protection of a domain, you can always change the context to bin_t. chcon -t bin_t CONFINEDAPP Will cause the transition to no longer happen. As far as racing to catch up, I agree, but the real problem is getting the xen developers or whoever to make sure it works with SELinux in enforcing mode before shipping an update.
I didn't bother with audit2allow -- I just went ahead and build a one-off policy module locally and loaded that. Fortunately, I knew enough to make that work, but many users do not. Changing the application context to bin_t is an interesting suggestion. The difficulty is that this change is not robust if the admin later runs restorecon or fixfiles. Also, it can be undone by a package upgrade, because the upgrade will create the new binary using the official context rules. Is the recommended resolution to change the local file contexts? If so, does the entry in file_contexts.local override the entry in file_contexts? In this particular case, there is already an entry for /usr/bin/rsync in file_contexts. If an entry for /usr/bin/rsync also exists in file_contexts.local, which one wins? Aside -- and this is NOT a complaint -- I think we need to get the theory of operation for the targeted profile documented. There is an awful lot of "forensics" involved in sorting this stuff out. I know about the NSA docs. Is there documentation somewhere else that I missed?
Currently for the naive user audit2allow is the best we have. semanage fcontext -a -t bin_t /usr/bin/rsync will work although the other tools will start to complain, matchpathcon /usr/bin/rsync /etc/selinux/targeted/contexts/files/file_contexts: Multiple different specifications for /usr/bin/rsync (system_u:object_r:bin_t:s0 and system_u:object_r:rsync_exec_t:s0). /usr/bin/rsync system_u:object_r:bin_t The prefered solution is to build a loadable policy module, especially where the transition rules missing could cause other problems, per my example of syslog. What did you local policy customization for rsync look like? It might be a common way of setting it up and I could update the global policy, or add a boolean.
The policy module that I built is attached. I would NOT hold it out as an exemplar. In particular, the cases for file_t are far too broad for comfort. What I wanted to achieve, informally, was: if httpd can read it, rsync should be able to read it in addition, rsync should be able to read /home/OPENCM. This module is working for me, but it's obviously a hack. Doesn't consider http_user_content_t. Doesn't impose a path restriction on the file_t cases (can this be done in a module like this?). etc. Another approach might be to write a module that simply states "rsync_t should be unified with bin_t". I do not know if such a rule can be expressed in a policy module, or if so, how to go about it. Background issues: 1. Already had /srv/www/... set up, didn't want to mess with contexts there. 2. Already had /home/OPENCM. Didn't want to set that to public_content_t because that would break opencm. 3. Assuming here that the path restrictions in rsyncd.conf will be honored. Because of the sensitivity of the /home/OPENCM content, it would really be better to express those path restrictions in the policy module as well. The larger problem here, IMHO, is a theory of operation issue. IIRC the public_content_t idea is a variant on something I suggested about a year ago. That's better than what we had, and it is good to have, but it is overly broad. What is really called for here is to be able to distinguish subtrees by path and state explicitly which tools can access that subtree. Problem, of course, is that the subtree(s) of interest will turn out to have file contexts of their own that we then need to (explicitly) permit. I'm not suggesting that anything this complex should be built into the base policy. Rather, I'm suggesting that a tutorial writeup on how to do this sort of thing would be useful. I'll even volunteer to do the wiki page if you'll be gracious enough to steer me on this. Hmm. I think that the construct I may be after is something of the following form: if the app is running in appcontext_t and the app is accessing a path matching regexp then the app should be treated *as if* it had been running in otherappcontext_t.
Created attachment 160052 [details] Hack policy for more permissive local rsync behavior.
I am running Apache (httpd) with a customized httpd.conf. When SELinux is enabled in Enforcing mode, it interferes with proper operation of the customizations. Using system-config-selinux, it appears that the only way to fix this is to disable SELinux entirely (which is what I have done out of necessity for the moment). It was enough trouble to learn the arcane http.conf syntax to get Apache to do what was needed; I certainly am not going to learn yet another config file language to configure SELinux to keep close watch over the altered Apache. Ideally, SELinux would read httpd.conf and set permissions accordingly, but it's fine with me if there were just some way to disable SELinux for Apache only. That way I could continue to enjoy SELinux protection for the many other services which are running without customization. I *thought* there had been such an option before, and I guess finding this bug confirms it. If there is going to be a GUI interface to tweak SELinux, turning it off for certain applications seems to be the most important knob one could want to turn. I hope to see these booleans return in a future release.
As stated above a simple hack would be to chcon -t bin_t /usr/sbin/httpd This will cause the transition not to happen. You might want to put this in the init script, since a relabel could be triggered to restore the standard context. If you ran selinux is permissive mode. setenforce 0, you could gather all of the avc messages that your customized apache environment is running with, and use audit2allow to generate custom rules as explained above. Finally with apache, sometimes the fix is as easy as changing the file context on your private directories. If you ran your custom apache in permissive mode, I would be willing to look at the avc messages that are generated.
If httpd is set to sbin_t, and an autorelabel or restorecon -R / is done, won't it revert? I don't object to the proposed solution, but a solution is needed that won't get undone under ordinary conditions of system administration.
Yes, but that is why I suggested changing the init script. The best solution is to do the setenforce 0; run the app; grep app /var/log/audit/audit.log | audit2allow -M myapp; semodule -i myapp.pp; setenforce 1 This makes permanent changes and leaves everything in enforcing mode.
Jonathan, the policy you have for rsync has file_t in it. Sorry I missed this from before. file_t means files that are unlabeled and this should never happen. You need to label these files, you can use restorecon on them, or if this is a mount point that you do not want labeled you can use mount options to set the entire file system. How are you using rsync, that it requires these reads?
I was responding to the exchange with beland. In my case, file_t went in there because that it is what audit2allow said it wanted. In my situation (as opposed to belands), labeling the files is not an option. For my case there *isn't* an apppriate label, because one of the applications touching that piece of the content doesn't have an selinux config. Respectfully, running audit2allow blindly is a fairly unwise thing to do. Audit2allow is certainly better than nothing, and it is a very useful tool, but I have seen it generate some pretty bad policies.
The idea of customizing my SELinux installation using command-line tricks and configuration files is missing the point. I know I could with enough effort make SELinux allow the Apache behavior I have today. But I don't really want to invest time and energy in doing that now, and every time in the future when the customizations change. I also don't know if at some point in the future Apache will be denied permission to do something it's supposed to be able to do when I'm not around to notice, and as a result some visitors to my web site will experience a needless error. Most people like me who examine the options in system-config-selinux won't bother filing a bug report or looking up the documentation to figure out how to change Apache's rules. We'll just turn SELinux off. There is a relatively simple solution that will enhance security for people like us - let us go back to being able to disable SELinux on a per-application basis in the GUI. If disabling SELinux for syslog causes problems, then either there should be no boolean for this application (and people can just disable SELinux entirely if they are having problems), or the problems that this causes should be fixed.
Beland: I'm in the same position that you are -- I don't work for RedHat. Speaking from th e perspective of someone who also administers systems on top of my regular load, I agree with you. In addition to the issues you raise, there is also the fact that this feature was well established and probably widely used, and was removed without notice. However, if you look above at comment #2, you will see that Dan also has a valid issue to deal with: disable_trans was breaking things. He didn't go into a lot of detail, but knowing a little bit about the grand hodgepodge that is the targeted policy, I suspect that resolving the issue requires a substantial policy re-architecture. I do not have the feeling that Dan is ignoring you. Rather, I have the feeling that he is equally uncomfortable with the current situation but is unable to offer a satisfactory resolution. Part of the problem, I suspect, is that the current policy set grew organically. It kinda works, so parts of it have a consistent theory of operation, but not all of it. Unfortunately, so far as I can tell, any theory of operation is documented only in the skulls of the SELinux team (Dan: if this is wrong, I'ld love a link to a design description. I've looked and not found one). The problem that we face in the large is that a policy system like this really *needs* a comprehensive theory of operation in order to be maintainable. Dan is deep in the swamp being chase by a wide range of alligators. He needs to break loose some concentrated time for the necessary effort, and he will need to be addressing other pending issues as well, so this will take a while. Dan: aside, your comment about AVC diagnostics in particular seems to be moot, since I get those all the time anyway and audit2allow doesn't know how to fix them. :-) Dan: is my characterization of the issue as a theory of operation problem fair? Would it help to have a scheme for expressing the dependency relationships between the booleans in the policy language (ideally one where the policy compiler could generate them)? I think that has negative implications for modular policies, because there is a forward dependency problem to consider. I haven't thought about it -- I'm just throwing this out in case it sparks a useful thought on this subject.
Permissive domains are about to be added to Fedora 9, kernel - 26 So I changing the version of this bug to rawhide. Will not be back ported.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
semanage permissive -a httpd_t Is now in Fedora 9, although it still needs the kernel updated.
Closing all bugs that have been in modified for over a month. Please reopen if the bug is not actually fixed.
The semanage manpage seems to indicate that "semanage permissive -a httpd_t" will allow Apache to do anything, but log warnings if it does anything it normally wouldn't be allowed to do. This is great, but if you are looking at the system-config-selinux GUI (I'm running Fedora 10 preview), there is no easy way to deduce this. Booleans to allow Apache to do certain things (like run CGI scripts) *are* once again exposed in the GUI, but the option to turn off enforcing for Apache entirely is *not* exposed. It would greatly improve user-friendliness for system administrators if either the "turn off enforcing for this service entirely" option was exposed in the GUI, or there were better documentation accessible from the GUI. (I don't have permission to reopen this bug.)
I have rsync_export_all_ro --> on selinux-policy-targeted-3.5.13-38.fc10.noarch I get denials when I am trying to rsync some (but not all) files in /etc Just an example: type=AVC msg=audit(1232056712.924:111989): avc: denied { read } for pid=11254 comm="rsync" name="/" dev=dm-3 ino=2 scontext=unconfined_u:system_r:rsync_t:s0-s0:c0.c1023 tcontext=system_u:object_r:home_root_t:s0 tclass=dir type=AVC msg=audit(1232056713.814:111990): avc: denied { getattr } for pid=11255 comm="rsync" path="/etc/gshadow-" dev=dm-0 ino=49994 scontext=unconfined_u:system_r:rsync_t:s0-s0:c0.c1023 tcontext=system_u:object_r:shadow_t:s0 tclass=file type=AVC msg=audit(1232056713.815:111991): avc: denied { getattr } for pid=11255 comm="rsync" path="/etc/gshadow" dev=dm-0 ino=50497 scontext=unconfined_u:system_r:rsync_t:s0-s0:c0.c1023 tcontext=system_u:object_r:shadow_t:s0 tclass=file type=AVC msg=audit(1232056713.822:111992): avc: denied { getattr } for pid=11255 comm="rsync" path="/etc/shadow-" dev=dm-0 ino=50007 scontext=unconfined_u:system_r:rsync_t:s0-s0:c0.c1023 tcontext=system_u:object_r:shadow_t:s0 tclass=file type=AVC msg=audit(1232056713.823:111993): avc: denied { getattr } for pid=11255 comm="rsync" path="/etc/.pwd.lock" dev=dm-0 ino=49393 scontext=unconfined_u:system_r:rsync_t:s0-s0:c0.c1023 tcontext=system_u:object_r:shadow_t:s0 tclass=file type=AVC msg=audit(1232056713.824:111994): avc: denied { getattr } for pid=11255 comm="rsync" path="/etc/shadow" dev=dm-0 ino=50539 scontext=unconfined_u:system_r:rsync_t:s0-s0:c0.c1023 tcontext=system_u:object_r:shadow_t:s0 tclass=file type=AVC msg=audit(1232056713.918:111995): avc: denied { read } for pid=11255 comm="rsync" name="run-session.d" dev=dm-0 ino=53354 scontext=unconfined_u:system_r:rsync_t:s0-s0:c0.c1023 tcontext=system_u:object_r:bin_t:s0 tclass=dir type=AVC msg=audit(1232056713.930:111996): avc: denied { read } for pid=11255 comm="rsync" name="audit" dev=dm-0 ino=51450 scontext=unconfined_u:system_r:rsync_t:s0-s0:c0.c1023 tcontext=system_u:object_r:auditd_etc_t:s0 tclass=dir type=AVC msg=audit(1232056713.935:111997): avc: denied { read } for pid=11255 comm="rsync" name="blkid" dev=dm-0 ino=49223 scontext=unconfined_u:system_r:rsync_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_runtime_t:s0 tclass=dir type=AVC msg=audit(1232056713.936:111998): avc: denied { read } for pid=11255 comm="rsync" name="cron.d" dev=dm-0 ino=49273 scontext=unconfined_u:system_r:rsync_t:s0-s0:c0.c1023 tcontext=system_u:object_r:system_cron_spool_t:s0 tclass=dir type=AVC msg=audit(1232056713.941:111999): avc: denied { read } for pid=11255 comm="rsync" name="cups" dev=dm-0 ino=51212 scontext=unconfined_u:system_r:rsync_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cupsd_etc_t:s0 tclass=dir
Current system-config-selinux can show permissive domains, Please do not attach random bugs on the end of other bugs.