Bitratchet

Bicycling, Photography and Programming

Grumpy thots on SELinux

I just spent an hour trying to get a Samba share running on Fedora 20.
It used to not take that long, I’m familiar with how to get Samba running,
how to create shares, and how to manage valid users and masks.

But when it still doesn’t work? Well, what other thing do you do–you
TURN OFF SELinux. Why do the Fedora guys wonder at the SELinux hate?
Because SELinux doesn’t return any hint that SELinux policy violations
are the root cause of the strange errors you get when doing even mild
customizations of services…like adding a Samba share.

Please…why cannot I see something like:

smbd: SELinux policy prohibits read of /home/jed/3plibs

?

Would that be so difficult? I guess those things get reported in SOME log, but
NOT IN THE LOG YOU LOOK AT, which is the logs for the service you are configuring.

jedreynolds

, ,
, , , , ,
←
→

6 responses to “Grumpy thots on SELinux”

  1. By it’s very nature SELinux is generally transparent to the user space. The SELinux libraries and utilities can be used by user space to become aware of SELinux, at least to some extent. In practice one generally does not desire that user space becomes aware because that requires that user space understands SELinux, and often SELinux is misunderstood, causing even more grief by bugs introduced due to wrong assumptions about SELinux etc etc.

    Does it really matter who denies what though? Push comes to shove its -EACCES. Generally it is either your application layer access control, firewall, DAC, or MAC.

    Besides that notification that you are suggesting that smbd should print does tell much useful other than that it is SELinux blocking as opposed to something else.

    My advice to you is to just get used to the presence of SELinux and by glad that user space does not try to be “smart”.

    • I expected a “suck it up” response on this post, that’s ok. You have technically correct points, but not helpful ones. Obviously, my problem is habits and technique. So how do *you* detect when SELinux is interfering?

      • To be fair, apps generally also can’t detect whether if its DAC issue , a firewall issue, All it knows it “access denied”. Why should SELinux or any other MAC framework be any different?

        Not to mention that this would be up to the app to implement.

        There are many way’s to implement some detection. For example i have a audit dispatcher plugin that listens for AVC denials, and spawns xcowesay for 3 seconds with the AVC denial. Not very useful, and arguably redundant but it is an example.

        I generally do not care about SELinux blocking untill it breaks some functionality. Then i will notice that and work down my checklist:

        1. Is it app layer access control? (see app logs)
        2. Is is my firewall? (see firewall logs)
        3. Is it DAC (check DAC permissions/ownership)
        4. Is it MAC (check your MAC logs)

  3. Next time you may want to use “journalctl -f –all” while testing samba. You’ll easily see the selinux error nicely coloured in red and a description of what to do in order to fix it.

%d bloggers like this: