SoylentNews is people
SoylentNews
Jack Wallen asks via TechRepublic
Has SELinux got you down by blocking your apps or causing general havoc? Instead of disabling it, discover how to use the SELinux Alert Browser to solve those problems.
If you're using a Linux distribution that takes advantage of SELinux, such as CentOS, Red Hat, Fedora, or SUSE, you know it can be a blessing and a curse. While SELinux is an incredibly powerful tool that goes a very long way to keep your Linux-powered machines secure, it can be a nightmare to configure. Fortunately, there is a tool called SELinux Alert Browser that can ease those troubles.
With SELinux Alert Browser, you can get quick solutions when SELinux is causing you issues. In fact, you'd be hard-pressed to find an easier route to solving your SELinux-based headaches.
[...] The Troubleshoot button will reveal possible actions you can take to resolve your issue. In some cases sealert will instruct you how to have SELinux stop auditing the issue; in other cases sealert will show how to generate a new policy module that allows an object (such as xenconsoled) access to a resource.
When SELinux Alert Browser makes suggestions, they will be in the form of commands you can run to solve the problem. If you agree with the suggestion offered by sealert, go back to the Terminal window and issue the suggested command(s). Hopefully, your issue will be resolved. If you're unsure that access should be allowed, I highly recommend doing research before issuing the suggested command(s).
Any Soylentils ever get so fed up with SELinux that you just disabled it? Think this might have avoided that?
(Score: 3, Interesting) by mechanicjay on Sunday February 12 2017, @03:56PM
A few places I've worked, have by default just disabled SELINUX support outright, or at least kept it in bitch mode. There are a number of big name software vendors whose first installation step is "Disable SELINUX". While in principle I really disagree with this, I tried to go rogue at work and say, "Well, at least i can try to run SELINUX on my stuff." This turned out to be futile -- if your configuration varies at all from a vanilla install, or your distro doesn't happen to ship an SELINUX module for whatever package you installed, you end up down the rabbit hole of audit -> new rule, audit -> new rule. There are situations where you need such a complex rule that you basically end up giving up, as the rules and syntax are really obtuse. Try building an SELINUX module for the Shibboleth daemon and mod_shib for Apache - I did it, but I don't understand the ruleset at all -- which is a great way to leave yourself exposed with a false sense of security.
It's strange that the article lumps Suse and Ubuntu into the SELINUX camp, as that's historically been primarily a RH/Fedora/Centos, thing while Ubuntu and Suse have tended towards AppArmor. AppArmor, by contrast has a sane way to audit and add rules, and even someone without a whole lot of AppArmor experience can grok a profile -- which is not the case for SELINUX at all.
That said, it this looks like it makes it marginally easier to get to the sealerts and build a ruleset, which is a good thing, but its definitely the opinion of many that SELINUX's ship sailed a few years ago.
My VMS box beat up your Windows box.
(Score: 2) by jmorris on Sunday February 12 2017, @04:40PM
Yup, that is my experience too. Every install I mess with SELinux a bit and then just turn the darned thing off.
If you use the "troubleshooter" all it does is write you a rule to bypass every warning. But since you usually do not understand what the warning was, why it was dangerous and whether the bypass is dangerous it quickly becomes security theater
And that is the problem. Nobody understands SELinux outside a small cabal at the NSA and RedHat. I even tried buying the O'Reilly book but it was obsolete, apparently before it ever went to press. So long as they can keep churning the fine details such that you find a half dozen websites all documenting a different and incompatible SELinux to the one you are working on they keep it a thing only the cabal can work with. So long as it remains a checkbox that keeps the RHEL contracts being renewed.
Basically I long ago wrote it off as more alien RedHat tech best ignored. Even on the most modern systems it remains a parallel reality, the rules don't really attach to files in that they more often that not will not copy with the file. Packages have to keep the rules in a separate place and at the first sign of problems you have to "relabel" everything. But the major filesystems have supported extended file attributes for longer than SELinux has been a thing so that Samba could properly support WinNT.
(Score: 2) by Whoever on Sunday February 12 2017, @05:03PM
It depends what you are trying to do. I have setup webservers that have SELinux enabled and this task wasn't too difficult.
(Score: 3, Insightful) by jmorris on Sunday February 12 2017, @06:03PM
Yes, if you do something utterly ordinary it all 'just works' but the slightest variation and everything breaks. Put home directories on NFS and watch how many SELinux rules explode. And that is a very common use case, isn't it? Then it gets worse. Go back to that web server of yours and try anything interesting. It is probably better now but mod_perl would break SELinux. Whut? Do they even test these things before enabling it by default? At RedHat? These are the morons who kept sound broken on Linux during the entire window of opportunity when people wanted off of Windows Vista. But because everyone is downstream of RedHat's alien tech it didn't matter what distro you used it was broken.
I think we need to admit there is a problem here. RedHat's economic incentives are all wrong. Their revenue model depends on Linux remaining stable on the server but not simple. And they do not really care what happens to the desktop. At all.
(Score: 0) by Anonymous Coward on Sunday February 12 2017, @07:53PM
My experience with SElinux exactly.
I've tried numerous times to tackle SElinux, and have never succeeded. Most of the blame is on the Fedora policykit being bad and lacking documentation.
Last time I just got mad at it, when I discovered Fedorapolicykit had rules for executables that didn't exist on my system. These rules enabled access when those executable exist ... but since they don't exist on my system, that's a security hole if an attacker can create one of those files. Such rules should only be added when the package is installed, i.e. at installation time.
I used to leave it in nag mode, now I just disable it.
(Score: 0) by Anonymous Coward on Sunday February 12 2017, @08:46PM
I've tried numerous times to tackle SElinux, and have never succeeded
So, do you think that the Soyvertised app and Jack's little tutorial might increase your chances of success in the future?
...or are you never looking back.
mechanicjay (Fristy) mentioned AppArmor.
Have you already gone that route?
-- OriginalOwner_ [soylentnews.org]