Bug 249457 - Regression: removal of disable booleans
Regression: removal of disable booleans
Product: Fedora
Classification: Fedora
Component: policycoreutils (Show other bugs)
i386 Linux
low Severity high
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2007-07-24 15:45 EDT by Jonathan S. Shapiro
Modified: 2009-06-26 16:01 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-06-26 16:01:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Hack policy for more permissive local rsync behavior. (416 bytes, application/octet-stream)
2007-07-26 14:15 EDT, Jonathan S. Shapiro
no flags Details

  None (edit)
Description Jonathan S. Shapiro 2007-07-24 15:45:48 EDT
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.
Comment 1 Jonathan S. Shapiro 2007-07-24 15:48:16 EDT
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.
Comment 2 Daniel Walsh 2007-07-26 13:22:42 EDT
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.
Comment 3 Jonathan S. Shapiro 2007-07-26 13:51:21 EDT
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?
Comment 4 Daniel Walsh 2007-07-26 14:00:49 EDT
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
/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.
Comment 5 Jonathan S. Shapiro 2007-07-26 14:14:42 EDT
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
  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

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
Comment 6 Jonathan S. Shapiro 2007-07-26 14:15:30 EDT
Created attachment 160052 [details]
Hack policy for more permissive local rsync behavior.
Comment 7 Christopher Beland 2007-08-29 21:41:16 EDT
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
Comment 8 Daniel Walsh 2007-08-30 10:17:11 EDT
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.
Comment 9 Jonathan S. Shapiro 2007-08-30 10:39:36 EDT
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.
Comment 10 Daniel Walsh 2007-08-30 11:14:10 EDT
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.

Comment 11 Daniel Walsh 2007-08-30 11:19:00 EDT
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?  
Comment 12 Jonathan S. Shapiro 2007-08-30 11:32:13 EDT
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.
Comment 13 Christopher Beland 2007-08-30 11:46:20 EDT
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.
Comment 14 Jonathan S. Shapiro 2007-08-30 14:36:56 EDT

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.
Comment 15 Daniel Walsh 2008-05-07 11:38:24 EDT
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.
Comment 16 Bug Zapper 2008-05-13 23:05:32 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Comment 17 Daniel Walsh 2008-07-02 16:03:11 EDT
semanage permissive -a httpd_t

Is now in Fedora 9, although it still needs the kernel updated.
Comment 18 Daniel Walsh 2008-11-17 17:02:32 EST
Closing all bugs that have been in modified for over a month.  Please reopen if the bug is not actually fixed.
Comment 19 Christopher Beland 2008-11-17 22:16:44 EST
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.)
Comment 20 Vadym Chepkov 2009-01-15 17:08:19 EST
I have 
rsync_export_all_ro --> on


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
Comment 21 Daniel Walsh 2009-06-26 16:01:54 EDT
Current system-config-selinux can show permissive domains, Please do not attach random bugs on the end of other bugs.

Note You need to log in before you can comment on or make changes to this bug.