13 ms·
Stop Disabling SELinux: A Real-World Guide
- hadfgdasf 10y agoI will continue to disable SELinux, and no number of arcane articles about how EASY it is will convince me otherwise. Stick that in your pipe and smoke it.
- saywatnow 10y agoYour loss. I agree that the way it's sold as "EASY" (caps appropriate) is a bit ridiculous, but SELinux does add a stong layer of protection from vulnerabilities in one service leading to total server pwnage. Ignore the rhetoric and try to work with it - the peace of mind pays off.
- jlgaddis 10y agoIt really isn't that difficult once you understand the terminology and methods. It is absolutely worth the effort to learn, in my opinion.
- sgt 10y agoWhat if an app does something during runtime that you had not catered for? This effectively means potential downtime for the app while your admins are trying to figure out why the app is failing. I agree SELinux adds something to the table, but the article shows two examples (httpd_sys_content_t and httpd_can_network_connect). Let's assume there is a third httpd_can_foo_bar that is required down the line. And then a http_can_bar_quux a few hours after that. All in all this can be a bit risky. Perhaps if there was an easier way to administer SELinux?
- corney91 10y ago1. Functionality that'll be used should be tested before going into production. 2. Using something like setroubleshoot will make sure any SELinux denials appear in the syslog so should be simple to diagnose, and sealert will tell you likely solutions. Personally I think that's how distros should be shipping SELinux, not sure what the downsides are. Note, I'm mainly talking about servers here. Personal computers always seem to have messily-packaged applications running, so I can see why people get annoyed with SELinux there (although I've never had a problem with Fedora, yet...)
- bostand 10y agoI bet you also refuse taking vaccines.
- jazoom 10y agoI don't see how these 2 things are in any way related.
- baq 10y agovaccines work and are inconvenient.
- drvdevd 10y agoI think SELinux is convenient or inconvenient depending on context. For example on Android I find it's mostly convenient because it's been (IMO) well integrated into the system in such a way that I will only have to dig into it if I'm building a custom ROM or debugging an issue with native code. I find the defaults on Fedora (and I guess CentOS also) to be pretty good as well, lately. However I have my reservations about trying to implement it on top of any system that wasn't designed with it in mind. And it's important to think of each Linux distro as a unique whole system design in this context. I have no idea how inconvenient it would be to try and start running SELinux on Ubuntu, for example, though I know there's support for it in the repos. I've considered it, but it's like taking a vaccine where the side effects might actually outweigh the benefits, on consideration.
- jazoom 10y agoSo by extension hadfg is an antivaxer? That's some pretty hardcore extrapolation you've got going on there.
- mocko 10y agoI read it as exaggeration for comic effect. Maybe a cultural difference - it's a common way to make a point here in Britain.
- devnonymous 10y agoJust my experience: Ever since it came enabled by default on fedora I've been using it in Permissive mode ie: don't enforce but notify about violations. IIRC, since the last couple of releases I've seen maybe a couple or so notifications, so the default set of rules out of the box on fedora are definitely much better now than they used to be. I might just turn it to enforcing mode.
- proaralyst 10y agoI've been using Fedora since 21 (I think) and I've never switched out of enforcing. Occasionally you get notified that Chrome has violated something but the notification explains how to allow it if you want to. I'd really recommend it, it doesn't seem to impact the system usability in any way.
- foobarbaz71075 10y agoI'm not finding that guide to be helpful in doing what the title describes, since there's many things apart from web servers -- it has just described a simple and specific task, without much of explanation even for that. And selinux offline documentation is not great, so the title seemed promising.
- sergioocon 10y agoI've been using SELinux in my Fedora the last 3 years, always on enforcing mode. No major problems, just minor policy changes needed that the helper was already suggesting and that were easily fixed. With the only exception that SELinux does not like my iPhone.
- onli 10y agoI just fixed a bizarre problem on Fedora by disabling SE. By the way, the user is using a PC I configured with used hardware, partly from me. It's supposed to be a just-works system, meaning that it runs Fedora and I did no special configuration at all. That was the error description I got: "When starting the network does not work. I have to do a lot of things to make it work." Later I got more infos: "It says there are 7 errors. If I let it fix it it has to restart and then works". It turns out that these 7 errors are all SE-Linux-Errors. Something about /etc/resolv.conf not being readable. The error helper suggests to fix it for now and also some command to fix it permanently, those commands fail and do nothing. So of course I just deactivated that SE-bullshit. Really, fucking vanilla Fedora on a mainstream Gnome3 desktop. What the hell are they thinking?
- testUser69 10y agoI've used Fedora on the desktop for about five years and never had this issue. Maybe they were thinking you shouldn't change permissions on files in /etc unless you know what you're doing?
- onli 10y agoI did not change any permissions. Like I said, no modification from my side. Vanilla Fedora.
- lima 10y agoIf you'd post the actual errors, I'm sure we could help you with that.
- 10y ago
- daenney 10y agoThe Gentoo wiki has an extensive and really good set of tutorials[0] on SELinux. It took me some time to get through those but it greatly increased my ability to work with SELinux. It does a good job of explaining the concepts themselves and help build some familiarity with the CLI utilities and especially the debugging capabilities. [0]: https://wiki.gentoo.org/wiki/SELinux https://wiki.gentoo.org/wiki/SELinux
- yousry 10y agoWhy should I not use GRSecurity? Comparison matrix; https://grsecurity.net/compare.php https://grsecurity.net/compare.php
- chrisbolt 10y agoWhy should I trust a page with checkboxes under GRsecurity and X's under everything else?
- a_bonobo 10y agoI guess because of this: >Since September 9, 2015, the availability of stable grsecurity patches has become limited to the commercial customers of grsecurity.
- pjmlp 10y agoProbably because those devs didn't found another way of getting the community to pay for their bills.
- deleted 10y ago[deleted]
- viraptor 10y agoWith RBAC you effectively have to create your own policy for the whole system. I'm not aware of any successful projects providing a full, generic profile. But ideally, you could be using Grsec without RBAC, but with SELinux.
- adakbar 10y agoIt brought shame everytime I need to config new production server, first thing I did was change to pemissive mode
- eikenberry 10y agoI never disable SELinux... but that is because it was never enabled. I use Debian and SELinux has never been on by default and if it were good enough it would have been. There is a reason it was never enabled.
- tremon 10y agoTrue, there is a reason, but the reason is lack of focus among the developers, not whether it's good enough. Selinux has been maintained for years by just one developer (Russell Coker), and that just isn't enough to maintain up-to-date policy files for all 20,000 Debian packages. Lately Laurent Bigonville has stepped in to share some of the load, but I have never seen more than 3 people in Debian's selinux team. It would take an explicit release goal to enable selinux for Debian, and part of that release goal would be requiring package maintainers to help with maintaining the policy files for their packages.
- dredmorbius 10y agoThe facts that: 1. The package has only one maintainer. 2. The package requires heavy maintainer intervention. 3. Shit's on fire, yo. All suggest that whatever it is that SELinux is meant to be a solution to, it's not a particularly good, or compelling, solution. Stuff that needs custom wiring for every single package (and at last count Debian was in the 50-60k packages range, though a fair number of those are extra, source, and documentation packages) suggests ... issues.
- drvdevd 10y agoOne could envision a scenario where much of that custom wiring could be auto-generated somehow (e.g.: with some kind of defaults + dynamic analysis). But the point is really - this is a distro issue and SELinux is a building block. If your distro is using SELinux and it's causing you no end of headaches consider that it may be your distro that's the problem...
- e12e 10y ago
- tokenizerrr 10y agoI want to, but this article was not enough. Say I have my own binary running as a service, and it has to do these things. What do I do? This article seems to be geared specifically towards nginx/a httpd. I should probably just read the manpages.
- kiallmacinnes 10y agoDid you read all the way through? To where he says his next article will cover exactly that?
- jfindley 10y agoUnfortunately, this is an area that could use some work. Tools for writing new policies are a long way away from what they could/should be. If you need something to work with SELinux that doesn't come with a policy you have essentially three options, in order of preference: 1) Develop a new policy from scratch. This is fairly hard, and the tools, such as they are[0], are not great. There's a couple of good resources out there, including [1] which has some good examples, and Dan Walsh's blog [2]. 2) Use audit2allow to generate a policy semi-automatically. The resultant policy won't be very clean, and will almost certainly be more permissive than it needs to be, but if 1) is too much work (and I wouldn't blame you for this), then this is the next best thing. 3) Run your binary in the unconfined domain (do something like chcon -t unconfined_exec_t /usr/local/bin/foo), but leave the rest of the system enforcing. This will mean your binary itself is able to do anything, but the rest of the system is still protected. Oh, and if you haven't read it before, you should definitely check out [3](pdf). 0: http://oss.tresys.com/archive/slide.php http://oss.tresys.com/archive/slide.php 1: https://github.com/TresysTechnology/refpolicy/blob/master/policy/modules/system/application.if https://github.com/TresysTechnology/refpolicy/blob/master/po... 2: http://danwalsh.livejournal.com/ http://danwalsh.livejournal.com/ 3: https://people.redhat.com/duffy/selinux/selinux-coloring-book_A4-Stapled.pdf https://people.redhat.com/duffy/selinux/selinux-coloring-boo...
- tokenizerrr 10y agoThanks, all of those links are very informative. Shame that it seems like quite a lot of work still to set up for my own applications.
- throw2016 10y agoNo Thanks! Given the never ending list of revelations Redhat's deep ties to the US security industry and the NSA are problematic. Why should anyone not already a part of the government security industry trust selinux? By not coming out openly and explicitly criticizing the US security services for their anti constitutional and blatant authoritarianism Redhat has demonstrated which side it is on. It has no qualms enabling and supporting this behavior and is not a principled member of the free software movement. Something for which it has yet to be held to account. Given the movement against Trump is exactly against this kind of authoritarianism the lack of scrutiny of tech companies like Redhat, Palantir and others is hypocritical. By not speaking out you are supporting these actions. The fact that it is an absolute pain to configure and representative of a user hostile software model makes it that much more easy to avoid even for those with more practical considerations.
- lima 10y agoSELinux is the least likely part of the kernel to contain a NSA backdoor :-)
- drvdevd 10y agoIt's important to understand that SELinux has ceased to be a pure-NSA development for a long time. For that matter, it has spread far beyond RedHat as well. Anyway, though I get the sentiment, SELinux is a great example of leveraging OSS regardless of whether you agree with the creators or not politically. That's a win for OSS in general because it means we don't have to like (or maybe even trust) each other to benefit mutually across the net. The best arguments against SELinux are purely technical because there are alternative ideas about how such a system could be implemented (see: App Armor for example).
- Proven 10y agoI call BS. I have 0 use for it. I wouldn't disable it as a matter of best practice, but it's too annoying.
- simias 10y agoThe problem with SELinux is that it's disabled by default on many distros. If you follow guides online that weren't written for a SELinux-enabled Linux install then it won't work. To make matters worse SELinux-related errors can be pretty arcane if you don't know what's going on. I'm usually a FreeBSD guy but I had to setup a CentOS 7 box a little while ago. I thought I was going insane when I couldn't get nginx to connect to a unix domain socket. After a hour of hair pulling and non-conclusive googling I finally understood that it was SELinux related. I will admit that after that I simply disabled SELinux and never looked back. The benefits didn't seem worth the hassle to me. If I want additional security and sandboxing I'd sooner use something like FreeBSD/solaris jails. It's not exactly the same thing of course but I find the mental model a lot simpler ("a machine within a machine") than SELinux's complicated and (IMO) hard-to-debug rules.
- lima 10y agoThe fix for that would have been: setsebool httpd_can_network_connect=1 audit2allow even tells you right away which booleans apply: tail /var/log/audit.log | audit2allow
- simias 10y agoThank you for that, that might be helpful in the future! But it kinds of demonstrate my problem with SELinux: when I had my unix socket issue I tried to debug my problem using my usual tools: strace, ls, ps, dmesg, etc... but I couldn't figure out what wasn't working right. All the permissions looked fine and yet I kept getting cryptic failures. With something like a jail, once it's set up I can just use my un*x admin experience without having to learn a brand new OS-specific (if not distribution-specific) set of tools.
- lima 10y agoWell, you get that with any security technology and it's just one of many things to be aware of when you use another distribution.
- sandGorgon 10y agosome things need a change to not NEED selinux. For example, lots of password files and certificates should not be stored in directories and files (and mucked about in selinux). They are better off in the Gnome-keyring (which is severely underutilized) for example - networkmanager-openvpn. Openvpn certfiles are usually shared by vpn providers and then when trying to load them, throws selinux errors. Here's the bounty to fix it - https://www.bountysource.com/issues/41582244-doesn-t-copy-referenced-certitifcate https://www.bountysource.com/issues/41582244-doesn-t-copy-re...
- tremon 10y agoActually, selinux also limits IPC. So moving things from files to gnome-keyring does not remove the need for selinux, it just changes the selinux policy from (access this object type) to (connect to this process type).
- sandGorgon 10y agoin these cases, it does. I dont have knowledge of selinux for IPC usecases... but in all the cases that I have seen, most of them have been file based access that are being guarded by selinux. Not that selinux is wrong.. my point is that these files should never have been used in the first place. Linux keyring is a kernel level infrastructure. However, we still have ssh keyfiles being stored in ~/.ssh . Not sure if I'm right, but it seems to me that openssh wants to be cross platform friendly. So it doesnt play with linuxism very well.
- drvdevd 10y agoInteresting. I'm surprised I haven't read more about the Linux kernel keyring infrastructure. Are you sure that portable openssh ssh-agent doesn't implement access to it?
- sandGorgon 10y agoin a few distros, they hack it together using "ssh agent" . You can read about it here - https://wiki.gnome.org/Projects/GnomeKeyring/Ssh https://wiki.gnome.org/Projects/GnomeKeyring/Ssh AFAIK - its the same story on OSX. I dont begrudge openssh - I'm not sure how it would work with multiple systems, but I dont know if it was ever a priority. But in this day and age of a "reloaded" Lavabit... these are infrastructure decisions that must be solved ! Interestingly, for all the hate that Lennart gets, he refused to implement "systemd-keyring" and suggested people should use the kernel level keyring service that already exists [1]. You can test it out using "keyctl". Remember however, that IMHO kernel keys do not persist across powercycles.. There is some kind of funky interplay between ecryptfs, kernel keyring and gnome-keyring that I dont completely understand (and is the basis of encrypted home directory in Linux) [1] https://lists.freedesktop.org/archives/systemd-devel/2014-June/020638.html https://lists.freedesktop.org/archives/systemd-devel/2014-Ju...
- patrickg_zill 10y agoThe problem is that I never had local users that might be malicious or that were prone to be hacked. The attacks for servers tend to be over the network and there are many different ways to mitigate those.
- drvdevd 10y agoThis is murky because the most basic UNIX isolation mechanism (UID/GID) is applied across all parts of the system: processes, files, etc. (in a nutshell). Thus, when you run some program locally, sometimes it runs as your user/group and sometimes a new user/group is created for it. From this simple abstraction springs the issue that any (potentially misbehaving) application running locally needs to be treated as if it were a user on its own: with all the quirks a random "user" could bring like deleting files, accessing private information, and so on. Hence the need for these finer grained access control mechanisms. Any program that you download from the Internet (every program most of us run) might as well be a remote user on your system, in a sense.
- lima 10y agoActually, the default Red Hat SELinux is exactly for preventing network vulnerabilities. Local users are unconfined. Example: your web application allows remote code execution. Even the default rules prevents most access (spawning a shell etc.) and generate lots of alerts.
- technofiend 10y agoFrankly I found SELinux a little inscrutable and not worth the trouble of learning since I didn't use it at work, despite otherwise being someone who is up for self-education on anything new and interesting. However the Redhat certified admin and engineer classes cover it with enough practical examples to make any SA functional with the tool. And as a former consultant learning anything people consider difficult whether or not it really is can be profitable. :-)
- hobarrera 10y agoSo, this is a guide about how you can configure a broken out-of-the-box security framework, trying to convince me to enable it? Thanks, but I'd rather start from something that works, and build adding security from there, not viceversa.
- laurent123456 10y ago> Jan 31 10:48:54 server audit[16067]: AVC avc: denied { name_connect } for pid=16067 comm="nginx" dest=8000 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:transproxy_port_t:s0 tclass=tcp_socket permissive=0 I think one reason security programs are sometime ineffective and end up being disabled is that they give problems to developers and sysadmin but no solutions. I wish that rather than messages like "doesn't work - too bad", these programs would output a solution as well, such as "consider setting `httpd_can_network_connect` to `true` to allow it". In some cases it might be tricky to propose a solution, in which case even a link to the doc would be useful like "check http://example.com/doc#456 http://example.com/doc#456 for more information". That would go a long way towards making security software issues less of a pain for those who aren't expert in the topic.
- drvdevd 10y agoThis is a great idea and reminiscent of LLVM to me...
- obelix150 10y ago"audit2allow -a" or "audit2why" will tell you what the reason for a denial is and potentially how to fix it. Pretty sure it will tell you to run setsebool to allow httpd_can_network_connect in this instance.
- snuxoll 10y agoaudit2allow is the single greatest tool I've ever used for dealing with SELinux, people need to hear it's name sung from the mountains. I actually write SELinux policies for software I develop, first thing I do is put them in the most restrictive context imaginable with no permissions, set SELinux in permissive mode and run the application through it's paces, at the end run audit2allow and there's 90% of the work done for you outside of defining fcontext's.
- blockoperation 10y agoIt must be used with care though, otherwise you'll end up with so many holes in your policy that you defeat whole point of using SELinux in the first place. Definitely don't use the output directly.
- baldfat 10y agoOpenSUSE as well as Arch, Debian and Ubuntu uses apparmor and I never had a problem where I had to disable it. apparmor is less complex but SELinux can be fine tuned at the cost of pulling out your hair with what security gain? The BIG ISSUE is the KERNEL SELinux and apparmor have the same policy with Linux Kernel aka both of them can be bypassed and a hacker can just focus on the Kernel.
- msimpson 10y agoIf system administration was carpentry, SELinux would be the glue. And sometimes, it's just easier to use screws.
- neurostimulant 10y agoI think one of the reason why people disable AppArmor/SELinux is due to bad experience spending hours trying to figure out why their service fails to run after a config update only to realize it was blocked by AppArmor/SELinux. They'll just disable it and says "good riddance". If you're running a headless server and can't figure out why your service suddenly can't start after a seemingly simple configuration updates (changing port, changing data directory path, etc), be sure to check AppArmor (Ubuntu) or SELinux (Red Hat distros) logs first.
- Ensorceled 10y agoAt my last gig we enabled SELinux as part of our PCI security procedures, I highly recommend it but be aware that there is a fairly big ramp up. It pretty much doubles the effort for most sysadmin tasks, even simple things like tweaking a server setting become multi-step processes. In my case, it was part of the reason I switched the team from DevOps only and brought in a real sysadmin.
- e12e 10y agoEh, "real" devops is having "real" developers and "real" sysadmins working in multi-displinary teams? Sounds like you went from NoOps (lolops?) to DevOps :-)
- Ensorceled 10y agoTrue, I should have put "DevOps" in quotes :-)
- rascul 10y agoI'll stop disabling selinux when I have a problem that it solves.
- bandrami 10y agoSome distro (Mandrake? Debian? This was a while ago) had a bad default SELinux setup for years that introduced a subtle vulnerability that wasn't there in boxes that had SELinux disabled. Knobs that can be tweaked can be tweaked wrong, and wrongly-tweaked knobs are security problems. Frankly I don't even like ACLs and capabilities for that exact reason: it's no longer immediately obvious what the actual permissions in a situation are ("let's see, the daemon is running in an unprivileged account, but it has CAP_SYS_ADMIN set, and this file is inheriting its ACLs from the parent dir..."). Making it more difficult to reason about security is generally a Bad Thing, and not worth whatever features that difficulty brings with it.
- bkor 10y agoPractically there's been many examples where SELinux restricted a security vulnerability. I think SELinux is way too complicated. Needing to know exact commands to turn error messages into something understandable is bizarre. That said, SELinux determines what is allowed. Having it introduce an additional vulnerability/permission just due to configuration is really odd. I tried searching for your example, but can only find security bugs, not configuration issues.
- bandrami 10y agoTurns out I was thinking PAX/Grsecurity back in 2005. Same principle, though: more knobs to turn = more knobs to turn wrong.
- cessor 10y agoI ran a centos server for a while (ran= not my responsibility any longer) with SE Linux and a tomcat portal app, as well as other, custom web apps (ruby on rails with a mail queue and mysql backend, etc). I always left it in permissive, because I couldn't figure out how to properly configure it. I tried understanding the principles behind it and configuring the different exceptions for several classes, but often, this didn't work (e.g. I had used wrong class, or enabled exceptions that were still blocked). The users of the rails app kept calling, asking me why this or that feature wouldn't work. It was impossible for me to configure all exceptions - to me this was not surprising, given the complexity of the software that we had installed. I simply deemed the apps too complex and too "feature rich" to configure all SELinux exceptions manually. I then understood that there is a different way: To set it to permissive, keep it running for a while and then generate an installable permissions profile, allowing all occured violations as some kind of permissable exceptions. This made sense to me, however it required downloading some dubious python script, that would create some dubious binary file. I got this to work, but then again, this or that feature was blocked. I finally kept it running on permissive. This is my individual story. The article makes it look as if it was really simple to configure it (When I started with SE I tried similar moves but never got it to work). So, is it just me, or might it be that SELinux just has a major usability issue?
- snuxoll 10y agoWhy aren't you testing things with SELinux before you deploy them to production? Also, if you constantly need to alter your policy it sounds more like your application is poorly-behaved, not that SELinux is your problem. audit2allow is a great tool for simplifying the development of SELinux policies, but it doesn't remove some hand-crafted modifications to policies, especially in regards to file contexts (fcontext).
- justanotherbody 10y agoKeep in mind there are a LOT of apps deployed on systems with SELinux with few, if any, tests Further, the divide between ops and developers in many cases leaves this as an unsolvable problem - it's not the dev's job to do sysadmin, and ops lacks the expertise (or time) to comprehensively analyze the code base You're right that this makes the app poorly behaved, but if that can't be addressed then... permissive mode it is
- devdoomari 10y agohow does app armor compare to selinux?
- throw7 10y agoNot one mention of dontaudit rules. The day I found out about them (years ago when I tried to use selinux in the "real world"), I said nope.
- njharman 10y agoHours I've spent dealing with security breeches (on Linux) - a few, false alarms. Hours I've spent dicking with selinux - too many before disabling it. OTOH I've been admining *nix from before Linux existed.
- fest 10y agoselinux is enabled by default on Android (since 5.0 or so) and if I recall correctly, is required for google to certify an Android device. IMO it definitely reduces privilege escalation attacks there. I wonder if Apple uses similar MAC system on iOS? Also, it is usually transparent for user app developers but can cause a bit of headache for platform/system devs. I just literally spent a day on an issue where android system service checks selinux permission but does not audit the denial (= no error in logs) under certain conditions. That was not a problem with selinux per se, but disabling selinux would "solve" the problem.