> 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 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.
"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.
audit2allow 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.
It 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.
This is doubly annoying when you're on a fresh install of some distro (in my case, Fedora) and it just starts whinging about files and services you've never heard of, before I've had a chance to do anything with the system.
"This service did the bad thing, supposedly", ok, so what am I supposed to do with that? Is the service at fault? or is the default SElinux config borked? or both?
If the answer is actually "no that's fine", then why am I being alerted about it?
Learning .Net now and this is one of the things that that I like about it: sometimes the error messages is a lot clearer and sometimes they include suggested solutions.
I 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?
Why 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).
Keep 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
Everyone keeps telling sysadmins they need to be able to write code, how about developers start learning more about how their applications are deployed.
I wear both hats, and then some more on top of that - if someone on my team is doing something that will make deployment and security difficult I make sure to nip it in the bud during testing.
The 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.
What specific software causes problems? I use SELinux on the desktop and have no issues with it other than occasional warnings which don't seem to effect anything. I develop a lot of networked applications and do a lot of stuff with Linux containers.
On the server I usually use Ubuntu and run custom server software running in a container and never have problems.
I just ran into one yesterday. I was pulling my hair out because rsyslog wasn't forwarding messages to logstash. I checked and double checked my configurations, tried different settings, and it all looked correct but it still wouldn't work. Finally an strace of rsyslog showed permission denied when attempting to send a message. Aha, SELinux got me again.
strace is seriously amazing for troubleshooting stuff that you can't just throw some debug print statements into. strace -f -e open -s 4096 -- whatever --foo is my typical usage of it (follow forks, only trace "open" calls (to see what a program might be trying to look for a thing), string size = 4096 so e.g. Paths don't get cut off, -- to say that you're done giving options to strace and all --options should now go to "whatever"). That + ps auxf | less and searching for a process to see how it fits into the tree + lsof -p [pid] + top and hitting c, 1, u (then typing the user of processes I'm interested in) or hitting < or > to change sort columns + netstat -lnp | grep LISTEN....are the basics of how i figure WTF is going on with a system I've just jumped onto. SELinux and systemd with the journal logging sometimes getting in the way of these flows unless you know what you're looking for and are vaguely aware of how they hook into things.
Wouldn't it have been easier to check the audit.log? Pump out the contents to audit2allow and you will have a nice new config that would allow your setup. Heck, it would even tell you if there is already a boolean for that config.
I really don't see any reason to disable SELinux. Maybe back in RHEL5 days, but not since then. Just educate yourself on some tools. It really isn't that hard.
Sure, it would have been easier for me to check the audit log, however the idea that it was an issue with SELinux didn't even cross my mind until I used strace. The vast majority of Linux systems I work on do not have it enabled.
You may not see a reason to disable SELinux, but not all Linux systems are RHEL, and don't have it enabled to begin with. I personally would not enable it on a system that did not design for it as a default.
I had problems with users not being allowed to upload pictures to MediaWiki. It was an internal use only machine so I had no problem with disabling SElinux but I would highly recommend working thru the pain on an internet facing box.
Thank 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.
That's just not true. There is plenty of security technology that doesn't require you to figure out new tools. There is security technology that doesn't have tools at all and there is nothing to figure out. The program either works correctly or it's buggy and there is no knob to make a buggy program correct.
And then there is security technology that is more or less understandable with knowledge of existing Unix tools. pledge() on OpenBSD, for instance, doesn't introduce new fancy tools. A program doing something it promised not to do will get killed with abort trap (which can, admittedly, be a little cryptic if you don't know pledge does that). In addition, the name of the binary, the pid, and the offending syscall is printed in dmesg. Perhaps it would be better still if the dmesg line included the word "pledge" as a hint & guarantee that you'd get relevant results on Google.
Well, "security technology" in the context of mandatory access control frameworks. Bad choice of words.
My point is that any ACL framework will require configuration, be it SELinux, AppArmor, Tomoyo, or pledge.
If you want to use pledge to confine applications that don't use the pledge API, it will get complicated, too (admittedly not quite as complicated as SELinux, but still).
SELinux writes denials to the audit log and you get plenty of relevant results.
pledge is obviously much more sane than SELinux, but someone has to write a policy no matter what technology is used.
Selinux MAC is painful coming from DAC and it has bitten me numerous times but depending on your environment and
exposure it can be a must have.
I wouldn't run an 'exposed' system that had SELinux support (and decent rules) without SELinux. Not discounting chroot, but given root a lot is possible in a jail.
Lxc has since 1.0 come with isolation and security as part of it's design and feature set. Docker started as a convenient approach to bundling up chroots - and AFAIK hasn't really made much of a real effort wrt security - other than somewhat ill-advised approach to tacking on (enabling) a feature here or there... (That's not counting external projects like rkt running images as vms etc).
Lxc is much closer to jails in that sense - but eg lxc/Lxd on Ubuntu is hardly (meant to be) a silver bullet.
The 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.
Frankly 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. :-)
I 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.
True, 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.
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.
whatever it is that SELinux is meant to be a solution to, it's not a particularly good, or compelling, solution.
Well, yes. Enforcing that surgeons wash their hands and wear protective clothing in the OR also isn't a compelling solution to surgeons, because it limits their response time. But the behaviour is forced upon them anyway (by either employment policy or insurance), because it is better for the patient. Selinux does the same thing: it requires security-aware behaviour from developers (by requiring the package to enumerate its expected behaviour beforehand) not out of convenience for the developer, but to improve the security for the user.
And that explains why Debian does not use it while Red Hat does: Red Hat can enforce selinux compliance by company policy, while Debian has to rely on every individual developer's judgement about the effort/benefit ratio. And just as with hygiene in medicine, the effort is internal while the benefit is external. That's why I said it would take a release goal (or general resolution) to effect that change in Debian.
Protective rules are not meant to be a compelling solution for those who have to abide by it. I don't see why we should expect selinux to be any different.
> And that explains why Debian does not use it while Red Hat does: Red Hat can enforce selinux compliance by company policy, while Debian has to rely on every individual developer's judgement about the effort/benefit ratio.
There's also this little thing that Debian has an order of magnitude more
tools and programs included in its official repository, and two or three
orders more packages. This alone pretty much explains why Debian cannot just
put SELinux into use, while Red Hat somewhat can.
The problem is that this is a security solution that can't just be bolted on. Consider that Microsoft had this exact problem when it stopped giving everyone administrator privileges by default, and the change was considered overdue rather than not-the-right-thing.
You hear it over and over again that blacklisting will always fail, and whitelisting is what needs to be done. Well, when you finally do go from default-allow to default-deny, you're going to have to fix every single package to keep things working.
Debian has accumulated a load of technical debt and has to pay all of it off before it can flip the switch on SELinux and see any benefit. It's understandable (if undesirable) that they feel that way. That doesn't invalidate the fact that they'll have to do the same for any whitelist.
With regards to SELinux, in that the other packages aren't configured for it. So, not exactly technical debt in the way we're used to using the word, but I thought it fit.
One 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...
Yeah I suppose it's not really tractable to automatically infer the total behavior of a program (halting problem?)... I had some kind of weird strace like mechanism in mind..
Perhaps static analysis to see which library functions are linked in the package (require symbols in all binaries) and then having a set of default policies per-package based on those (including like you said, "this program never calls X, is not in category Y, therefore it doesn't need to be able to write to /path/to/Z" and so on)..
SELinux is meant to be a solution to a "check a government acquisition checkbox", and is invested in mainly by Red Hat and others wanting to sell to the USG. Hell, it was originally developed by the NSA for USG-internal systems.
I 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?
You mean the actual error message? Sorry, it's already solved now and I didn't write it down. It was in Spanish, so I also don't remember how it was worded. But its content is correctly described above: Unable to open /etc/resolv.conf.
And btw, that is exactly what I don't want. I do report errors, I solve bugs. But I don't want to debug SE-errors, which just because of its paranoia makes perfectly normal usage impossible, so far that distros that enable SEL spit out errormessages immediately after installation.
The main value in SELinux is to protect apps against things they should never be allowed to do (like your web app reading /etc/shadow or notepad listening for network connections) so that even if they get hit with a 0day, they're still not really vulnerable because the SEL stuff blocks all the bad things they could do. It really truly works in practice to prevent a bunch of bad stuff. In reality though, most people just disable it because it's a pain to learn and deal with.
I know. But thanks for the answer. It is not what I meant, but it responds to what I wrote.
A security-solution that makes normal use impossible is not a solution. Security solutions never work if they make usability worse. SELinux goes farther, it also makes functionality worse till impossible. That is what I meant when I wrote that I don't see the point of it.
Something like that can be a good solution if you are manually hardening a specific process. As a general security solution it is completely unfit. I don't see the point of pushing it for that. Fedora should never have activated it.
I'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?
> I've been using SELinux in my Fedora the last 3 years, always on enforcing mode. No major problems
I think the only problem I've encountered has been when Virtual Box (or was it VMWare?) tried to compile and install its custom kernel-modules, while using UEFI with secure-boot. They wouldn't load, because they weren't signed. Took me some debugging to figure out what was going on, but it was easily bypassed.
The solution was to disable secure-boot and just boot UEFI in "regular" mode. Felt a bit like fixing things by running as root/admin, but apart from that one story, I've had absolutely zero other issues with SELinux. Fedora has implemented it really well.
Microsoft's Secure Boot in the UEFI isn't SELinux[0]. It's actually not difficult to get VBox/VMWare to play nice with secure boot[1], once you've generated your custom signing keys. I keep a .sh on my machine to sign the latest kernel after each `dnf update`. Weirdly, my laptop had trouble booting with Secure Boot disabled so I was forced to figure out how to get them to play nice.
Eh, "real" devops is having "real" developers and "real" sysadmins working in multi-displinary teams? Sounds like you went from NoOps (lolops?) to DevOps :-)
I 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.
Just 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'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.
Some 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.
Practically 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.
I 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.
Unfortunately, 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).
audit2allow takes care of 90% of the work for you, the rest is removing extraneous permissions and defining file context's (fcontext) which is pretty simple.
Really, it's as simple as this, I swear:
1. Write an empty policy for your application, defining a type for your binary (myapp_exec_t) with no permissions at all. Label your binary with this using chcon.
2. Set SELinux in permissive mode, run your application through it's paces.
3. Run audit2allow to get a decent policy to start with
4. Figure out where your application stores data on disk, if at all. Create another type (myapp_t) and label those directories with it (you shouldn't be writing outside of these directories by default, if you allow it to be changed in a config file the administrator can label new directories with semanage), then grant your application access to this type. Also make sure the installed path of your binary is labeled with your myapp_exec_t type.
5. Clean up the messy policy that audit2allow created if so desired, it's likely more permissive than necessary and not overly pretty. This will become easier as you work with SELinux policies more.
6. You're done
This will be time consuming the first couple times you do it, but you'll get quicker at it over time like anything else.
OpenSUSE 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.
It's trustworthy, it's just misleading. GRsecurity is a whole suite of security related patches/modules that SELinux/Apparmor don't do and have never claimed to do because they're 'just' about MAC.
With 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.
some 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.
Actually, 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).
in 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.
Gnome-Keyring does not use the kernel keyring facility (correct me if I'm wrong).
It also doesn't limit access in any way. Anyone who can connect to the keyring socket gets access to everything. How is this better than storing it in files?
It is NOT asking you to do some specific openvpn restricted setting. Its basically setting it to the same permission level as gnome-keyring. Except - not even password protected. And the biggest issue - obviously an end-user has to muck about this stuff.
Interesting. 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?
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)
Gnome-keyring is a poorly documented, DE specific solution that will rope in libdbus abnd a dbus service as dependencies. There are few circumstances where gnome-keyring is the answer.
"libsecret is a library for storing and retrieving passwords and other secrets. It communicates with the "Secret Service" using DBus. gnome-keyring and ksecretservice are both implementations of a Secret Service.
I didn't say gnome specific, I said DE specific. There's only two implementations and both of them can only be trusted to work correctly if you run them in combination with their respective desktop environment.
My big complaint with gnome-keyring is that it took over (replaced) GPG agent functionality but didn't bother implementing all of it (it doesn't support smart cards, for example).
selinux 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.
Actually, 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.
This 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.
I 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.
Your 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.
What 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?
1. 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...)
No 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.
It'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).
there was that one program..."system-something"....system-A ? was it ? or system-B ? or , hmm. "system-C". something like that, just...might have a vulnerability or two ?
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 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.