Yes, people/sysadmins should take their time to properly configure SELinux when things don't work, instead of just disabling it completely for good. I tried for a whole year in a place where we used CentOS, and then finally I gave up, too many hours wasted in finding the right conf for this new program or configurations etc.
Watching a 15 minute selinux tutorial video will give you a moat ahead of 90% of the community but it won't matter because management kind of agrees that anything that slows you down has to go, and security policy is ultimately just a type of insurance rather than a revenue generating activity. Disabling selinux reduces cost today so we might as well go for it.
I do think it is worth having on any public webserver since it's only a matter of time before your app gets popped and you want that sucker in jail, but I gave up on internal servers a long time ago.
What sort of disaster area do you work in where it's the developers job to tell security ops how firewalls work?
- Network ports the service listens on - What security permissions does the application need - What commands have to be run so the application starts - What platform does the service use? Java, Node, C#, C/C++, Go, something else? - What GIT repository or repositories contains the service's code? - How does the build work? - What needs to deployed to the machine? - Any configuration changes the application needs
There are also a lot of join decisions where the operations engineer and the software engineers have to work together. Here are some examples: - What cloud will the team use? (AWS, Azure, GCE, etc.)? - What cloud technologies will the team use? - What database will the team use? - How will logs and alerts work? - How will the on-call rotation work?
My main point is you cannot just tell an operations person to deploy something and expect good results. They will have a lot of reasonable questions and software engineers should be able to answer them.
Is there any reason that you do not know what your application can be expected to connect to? You wrote the thing, right?
I work with a lot of external vendors who offer self-hosted software and a really common refrain is "it must be a network problem" but these guys are universally unable to describe their application's networking requirements.
It usually goes like:
“What are the outgoing ports?” “1024-65535, I mean, the app is using X language’s standard library to make an HTTPS request.”
“What are the IPs we have to whitelist?” “You can either allow app.example.com or take AWS’s IP range JSON file and allow all of those, we don’t control what IP gets assigned to AWS’s API Gateway service”
Then some cloud provider’s SA/SE gets looped in to say the same stuff to the security team.
Some exec then gets escalated and approves this as a risk.
Tale as old as time.
On OpenSUSE/MicroOS who is employing SELinux boot takes about 5 minutes on every kernel change, because of home-relabel. I hear you, that they probably do it wrong, but that's what you get with SELinux. Not enough to push me to disable SELinux, but maybe to avoid SELinux distributions in the future.
https://www.ctrl.blog/entry/selinux-unmanageable.html
I'm not going to waste my time fighting SELinux to stop non-existent threats (I'm just using a desktop and I'm not a high profile target). Too many false positives and I'll just turn it off. And in my experience there are always too many false positives.
It's painfully obvious to me that the people who create SELinux and its documentation live in some alternate universe where they don't do anything the way I do, so I just turn it off.
It won't carry you all the way to applying policies via Ansible or RPM packages, but definitely took me from running random audit2allow commands to taking a more holistic view of my SELinux policies.
It also looks like a long read but if you fast-forward through chapters that aren't relevant to you (looking at you IPSEC) it isn't such a slog.
> it will give you the commands to fix it
Usually it's a crap you should not apply to the system.
A system which is easy to use securely will stay secure, a system which is difficult to use securely will be insecure.
I used to work at a payment provider and we had to deal with lots of monitoring and security stuff. Some of it was (obviously) busywork and needless checkbox filing, but other parts were genuinely useful. Setting up systems was tedious and difficult, but ultimately worthwhile and necessary.
HP at one point said to "chmod -R 777 /sbin" in their ArcSight install documentation, and that's a 'security' product.
-- A developer whose app needs to run as root (for a well-documented reason, and with a tight systemd sandbox hiding most of the filesystem from it)
SELinux is complex, badly documented, policy code is obscure macro incantation, and basic debugging tools often aren't installed out of the box on server distros (such as audit2allow). But for the day to day administration of systems, policies are included for distribution packages and most issues can be fixed by enabling a boolean here and there, and relabeling files.
The principles, basic admin & debugging part can be learned in a couple of hours, and when you have custom service software, you can throw it in /opt and have it run unconfined (ie: not subject to SELinux rules).
In principle, yes. In reality I've gone looking for a resource that I could do this with and come up short.
(I am starting to get really annoyed at things where I can find a million "paste this bit to do that thing" and there are so darned many of those on the internet that any hope of finding a good resource that gets to the underlying structure such that I can figure out how to do these things myself is virtually nil. It seems like this is getting worse as the search engines continue their trend of taking your query as a vague suggestion of the sort of thing you're looking for.)
It won't make you an expert but it takes the voodoo out of the whole process, if that makes sense. And it is reasonably short if you skip the stuff that you're (probably) never going to configure like passing labelled traffic between hosts with IPSEC.
The underlying concepts of SELinux aren't so hard but trying to manage it in any sort of coherent way is a nightmare - up to and including the provisions in it for a network based policy server component which just never appeared.
And it sucks! In theory it does so many things we really really want, and should do more. Like I as a user have a great interest in ensuring my home directory files follow sensible markings based on their content - my SSH keys, AWS keys, or banking files all exist in different logical zones of control.
And this is a concept SELinux can handle...but the tools are just so bad at surfacing it.
Then again, Disabling SELinux is necessary. For example, cPanel requires disabling SELinux on CentOS, AlmaLinux OS, CloudLinux, and Rocky Linux. AppArmor is fine on Ubuntu (https://docs.cpanel.net/installation-guide/system-requiremen...).
My servers all run with selinux, it's really trivial. Just the ssh client and tailscale recipes are missing by default. Selinux gives you precise choices if something is rejected.
Is this poor design or simply, not designed _for_you_?
I agree, its a royal pain to manage, and it might be overkill for a small shop trying to lock down their web server. Thankfully there are other solutions, and operating systems that may better fit your use cases.
https://en.wikipedia.org/wiki/Common_Criteria
If you are looking for a justification to excuse bad security practices, you won't find it in the origin story of SELinux.
I find it enlightening to read what kinds of justifications the proponents of SElinux use. It's never about the quality of the software; it's about how there's more band-aid tooling to make it easier to work with, or about how it's not as bad as it was, or that it gives you all these knobs and levers to have more control. It's not what you focus on when you're serious about quality software engineering.
Imagine if we were talking about something like Gnome or the Windows 11 interface: yeah, the interface is a real pain to navigate, but we added even more menus and buttons and the rightclick menu is twice as long now, so you can do even more stuff with it, and we even added Clippy back in to help you when you get stuck!
SELinux is designed to fulfill to primary goals. First, to secure the messy and complicated Linux architecture. And second, to be flexible enough to accommodate (highly) complex security architectures, as well as potentially unique and/or unforeseen needs. With that in mind, it's difficult to imagine any equivalent being practically more simple and/or elegant than SELinux.
The primary problem with SELinux is the broad lack of experience amongst users and sysadmins, opaque documentation, and primitive tooling. And in many ways, it is a negative feedback loop. If SELinux was used everywhere, improvements to its documentation and tooling would naturally follow.
You're describing the linux architecture as messy and complicated, but that describes the SELinux architecture as well; if complexity & mess are bugs that should be squashed in pursuit of security, SELinux is ill-suited to the task.
> And second, to be flexible enough to accommodate (highly) complex security architectures, as well as potentially unique and/or unforeseen needs.
>> It's technically capable of any kind of restriction a bureaucrat might envision
Sounds like we're on the same page there. Or at least looking at the same phenomenon.
Your last paragraph is definitely outside the pattern of justifications I listed, but it's not much better: you're just blaming the users. Sysadmins use all kinds of complex software to accomplish any number of delicate tasks - if the tool is well-built, they don't tend to complain that it isn't. SELinux is not. Don't blame the user when the tool's at fault.
This is fundamentally not true. Don't buy into the aggressive marketing. OpenBSD has a less secure design than pretty much any modern Linux. Their reputation for security is based on disabling things by default when it wasn't common 20 years ago, that's pretty much it.
First of all "OpenBSD stands on the logic of its own merits" what in the actual heck?
OpenBSD has had two remote holes in it's default install and importantly, *no mechanisms in place or restrict what can then be done*. That's not in line with a secure system.
You're vastly overstating and assuming the merits OpenBSD has, and then even worse, assuming logic exists based on that to support your position. I would say it doesn't, and I challenge you to show your work and demonstrate otherwise.
SELinux is a mature product that has seen widespread use in enterprise deployment and has real world examples of stopping attacks that OpenBSD couldn't hope to on it's best day.
If you want to go by merit and logic and not assumption and marketing, then SELinux will come out on top every time. It's actual, provable, tested security, not dreams and half-measures.
Hypervisors predate Unix, in fact they practically predate general purpose operating systems as a whole. The reason hypervisors came first is because they are substantially more simple than an OS. Tens of billions of dollars has been spent on virtualization technologies because of its reliability.
Sure, a virtual machine running on a type-2 hypervisor like KVM looks like a complete mess. But the sad part is that such an architecture is easier to secure than an operating system, whether OpenBSD or otherwise. Raadt may disagree, but AWS, Azure, GCP, etc depend on hypervisors/virtualization, not OpenBSD.
You're describing the linux architecture as messy and complicated, but that describes the SELinux architecture as well...
Well, yes. SELinux has to cope with the deficiencies of Linux. I'm not pretending otherwise.
...if complexity & mess are bugs that should be squashed in pursuit of security, SELinux is ill-suited to the task.
The problem is that the market settled on Linux, despite its "complexity & mess". SELinux isn't nice but it's the most concrete solution available today. Indeed, after twenty years of criticism, no one has been able to design a competent replacement or alternative.
>> It's technically capable of any kind of restriction a bureaucrat might envision Sounds like we're on the same page there. Or at least looking at the same phenomenon.
There is a material difference between our viewpoints. The government has systems running in a dizzying amount of configurations and environments. Moreover, government agencies and government contractors operate in a far more dangerous security environment than the vast majority private companies. Perhaps your workplace doesn't need SELinux, but companies like Lockheed Martin or Aerojet Rocketdyne definitely do.
...you're just blaming the users.
Maybe it seems like splitting hairs, but I'm not blaming anyone. Rather, I was lamenting over the bad situation of things. After all, I've been there as a new sysadmin. Trying to grok SELinux for the first time is not a pleasant experience.
Don't blame the user when the tool's at fault.
Look, if security isn't important for someone and/or their organization, then fine, don't bother. However, we have seen time and time again that compromises in supposedly "unimportant" systems ends up causing quite a bit of harm.
Ultimately SELinux exists because of the shortcomings of Linux itself. Nothing has replaced SELinux because genuinely securing a Linux system is extremely difficult and it fundamentally cannot be made simple.
Yes, money has been spent, and cloud infrastructure built, on hypervisors because of their reliability, and because they are selling virtual machines. But reliability, while paramount, is not security, and the goal is to sell VMs. OpenBSD, with its focus on security over performance, is the wrong tool for the job.
> coping with the deficiencies of linux
Good designs can take a messy domain and provide a clean interface on top of it. SELinux does not.
SELinux is partly a big matrix of tags, with definable security associations between any two such tags. That's great when a bureaucrat in a defense contractor security department writes up some new policy definition - you never know what they might come up with - and I would not make the mistake of assuming security is well-informed on the internals of Linux when they write those rules. SELinux is elegantly designed to be as granular as needed to accommodate that. But that's what it's designed for: checkbox security within massive agencies.
> it's all we have
Yes, I agree, it's the only thing that can accommodate that kind of security; since few people outside regulated industries are interested in catering to it, there's not a lot of push to make something else to fill that niche.
> the user or the tool
Arguing that security is important is not relevant to justifying SELinux. I will agree though, it's definitely very hard to twist a Linux system into a shape that fits bureaucratic security policies.
Then in practice someone ends up writing a couple policy statements and filing a couple forms then disabling it anyway, nearly every time.
If that’s the case it doesn’t need to actually work in practice, just hypothetically.
It's not the only project like it, it's the one that is most well known because it has the NSA attached and because it got incorporated into the main kernel.
It works in practice, absolutely, but most people are too intimidated or lazy to put in the effort to learn it.
I couldn't find it in the Debian spec (probably because it uses AppArmor), but the RHEL benchmark has these.
Currently, server level 1 only requires permissive mode:
https://www.tenable.com/audits/items/CIS_Red_Hat_Enterprise_...
CIS Red Hat Enterprise Linux 9 v2.0.0 L1 Server — 1.3.1.4 Ensure the SELinux mode is not disabled
https://www.tenable.com/audits/items/CIS_Red_Hat_Enterprise_...
CIS Red Hat Enterprise Linux 9 v2.0.0 L2 Server — 1.3.1.5 Ensure the SELinux mode is enforcingRegarding how to do that, it's left as an exercise to the PhD holding student.
AppArmor is simply less granular. For example, it doesn't provide true RBAC or MLS security models. It also uses paths instead of inodes, so a hard link can be used to override some policies.
So it just depends on what the exploit or attack is trying to do. If an attacker gets root and is trying to overwrite a file, they may be able to. Maybe they can't, but they could probably still execute any code they can write and compile themselves. And perhaps they can write to other files and do damage.
SELinux and similar systems allow a lot more granularity. Programs and users can only talk to explicit what they are allowed to talk to, and maybe you want to limit the access to say, append instead of full write access.
It just allows a lot more granularity and restriction, that's the difference.
The link rules can get pretty granular and seem explicitly designed to prevent that scenario.
https://man.archlinux.org/man/extra/apparmor/apparmor.d.5.en...
> they could probably still execute any code they can write and compile themselves
Assuming the AppArmor profile allows writing to and executing the same files. Which isn't particularly common.
> maybe you want to limit the access to say, append instead of full write access
This is possible with AppArmor.
It's still an inherent weakness. No getting around that really.
> Assuming the AppArmor profile allows writing to and executing the same files. Which isn't particularly common.
I don't really want to try and come up with examples just so you can show there might be some hacky way of accomplishing something similar to what SELinux can offer - it would be missing my point.
Point is there's a lot more you can do under AppArmor than SELinux. AppArmor isn't as granular and you can't lock down a system to the same extent, period. Is it good enough, sure. Is it better than nothing? Absolutely. Is it comparable to an optimized SELinux config? Not remotely.
> This is possible with AppArmor.
See above.
Yes.
> Literally every example you gave of AA not being "granular" enough was flat misinformation.
No, there was no misinformation, and this stance you're committed to defending is one of the most bizarre stances I've ever come across.
There can be no question that SELinux is significantly more granular than AppArmor any more than there is that the earth is not flat. Looking at the introductory documentation for both systems should be more than enough to make that abundantly clear to anyone.
> There are dedicated rules to prevent writing and executing the same file, prevent using hardlinks to gain privileges, and prevent overwriting a file that should be append only. No hacks here. Just facts.
So just before I put more effort into replying to you, I want to be 100% clear on your stance. If I am paraphrasing or misconstruing, please correct.
It seems like you are claiming that AppArmor using hardlinks is not any sort of vulnerability or weakness and cannot be, and has never been bypassed? Is this a fair reading of your position?
Can you offer some examples of things you can restrict with SELinux that you wouldn't be able to with AppArmor?
Only valid answer in the thread has been port bindings - AppArmor's network rules don't allow restricting port number, but SELinux can do that.
You tried to claim that SELinux could prevent processes from overwriting files instead of just appending to them while AppArmor could not do the same, but that statement of yours was easily disprovable -- the man page of apparmor.d shows that append-only rules are supported. If you don't want me to call your statement misinformation, then maybe invent another word because that is the only word I have to describe what you said.
I listed some of the ways AppArmor falls short, which you dismissed.
If I know an object is 3x3x3 feet, and we have a box that is 5x5x5, and another object that is 7x7x7, I don't need to thoroughly test every aspect of these items or even see them to know one of the won't fit in the box.
> Only valid answer in the thread has been port bindings
Not true. AppArmor lacks several of the models SELinux does, and thus, as has been said, is less granular, and thus, and as has also been said, it covers less area than SELinux does. AppArmor doesn't even consider user accounts as far as policy decisions go, and you can't bind policies to user objects. You realize already what a limitation that is, right?
It's sufficient to look at the designs of both systems to see this, see where one falls short, and not need practical examples to understand.
If you want practical, real world examples of SELinux blocking something AppArmor couldn't, as I said to someone else, a comparison of Debian and redHat security advisories should show this, as I would think it is extremely likely that Debian would significantly less often be able to say the issue isn't a threat if AppArmor is enabled vs RHAT saying the same for SELinux.
But, you want a setup. OK. Does AppArmor allow you to basically take root out of the equation entirely, by assigning only the capabilities a user needs to run specific programs (e.g. like binding a port under 1024) to a non root account? Does it then allow severely limiting the root account so it can't really doing anything and 'getting root' is pointless because you can eliminate the entire concept of an all powerful account? No, it doesn't, and there is plenty more it doesn't allow because it's a simpler and more limited system by design.
> You tried to claim that SELinux could prevent processes from overwriting files instead of just appending to them while AppArmor could not do the same, but that statement of yours was easily disprovable
You're right, this was my mistake. AppArmor either didn't have that functionally the last time I really played with it, or I forgot it had it. That's a bad example, sure, but the overall point is still perfectly valid.
> If you don't want me to call your statement misinformation, then maybe invent another word because that is the only word I have to describe what you said.
As far as AppArmor being able to enforce append only functionality, sure. As far as anything else, not so.
It's been a while and we hacked around it, don't remember how. Except that it was not the #1 solution, disable SELinux altogether.
And I don't agree with the article that containers do not add security. Container runtime implements namespace isolation, seccomp filters, etc. and that reduce the attack surface, comparing to running the software directly on the host OS. More importantly in this discussion, it is convenient for sysadmins.
There is no perfect security anyway. And I don't sacrifice convenience for national security level security :)
Most of the places who used CentOS for a 'free' Linux ended up shutting it off, though.
> The policy language and tooling is cumbersome, obtuse, and is about as appealing as filling out tax forms.
If a security framework is so terribly complex and hard to use, then people won’t use it.
OTOH, look at how OpenBSD or OpenSSH approach security: simply primitives which are well documented and easy to understand.
The only reason SELinux even works in the few scenarios where it does, is because the operator had immense amount of resources to pour into it. This itself is another sign of how bad the design is: it’s so complex that no small team of humans have ever been able to use it.
Sometimes, when the developers make a mistake, which is unavoidable in a large project, it is nice to be able lock down applications as the administrator.I just don't think SELinux is the right tool, because the chance of you making a mistake in the configuration is pretty high. The functionality is there, but it needs to be easier to write policies and maybe that comes at the cost of some flexibility.
On the other hand, the administrator knows their system better than the developer. There could be certain network connections or file paths that you want to block on one system but not on another.
I'm hoping it sticks. Just check audit logs when you get an error, it is not that hard, right?
These days that's just laziness/fear, and it's a shame to see it. It doesn't even make sense any more.
One crucial change for the better was leaving third-party software in a permissive state. From that point onwards, disabling SELinux is cargo-cult sysadmin'ing.
SELinux is not hard if you understand its basic principles. But no one bothers, because SELinux is the bogeyman.
Yes, writing policies means getting knee-deep in macros, and it's hard because many services try to access anything and everything. But almost no one needs to write a policy.
At most you need to tell SELinux that some non-default directory should have some label. That's not hard.
But that's exactly what I would like to do! I've never seen a real guide for how to set up a policy for a custom daemon I wrote myself. Or when a specific software doesn't come with a policy.
Many years ago I decided to face the Bogeyman and went from knowing very little about SELinux to writing a policy from scratch in about a month. The policy is simple enough (but realistic) that it might help in the absence of a guide:
https://github.com/carlosefr/kyoto/tree/master/selinux
I used it as an example in a couple of talks, whose slides might also provide additional context:
https://github.com/carlosefr/public-talks/blob/master/presen...
In my experience, it's not just directory labels ("semanage fcontext -a -e ..." and friends). You also need once in a while to set some booleans ("semanage boolean ..."). Yes, it's not hard once you know about it.
We don't disable SELinux.
SEL seems to work under the premise that if it’s too complicated for you to use, the attacker has no chance.
Few will instead read the RHEL provided documentation. Then they could maybe figure out whether there's simply a tunable (getsebool -a) which would enable the desired behavior, or if properly labeling files (semanage fcontext / restorecon) would do it, or even take the steps to add to an existing policy to allow for a specific scenario which somehow was not implemented. Even adding your own policies "from scratch" is certainly doable and provides a great safety net especially for networked applications.
Anyway... we all know disabling security or not implementing it in the first place can really save you a lot of time. At least in the short run.
The way I put it to my clients, and staff, is simply that security comes at the cost of convenience.
If you want to dive deeper: "SELinux System Administration" by Sven Vermeulen.
This is so funny because whenever I suggest Fedora Silverblue to a moderately experienced Linux user who wants a simple distro, the first thing I do is recommend turning SELinux on permissive mode, and I get a bunch of comments hand wringing about how you shouldn't do that.
It's almost like a silent filter working in the background of your OS that doesn't even tell you when it blocks something is a pretty user hostile feature and no one wants to learn how to speak SELinux so they can effectively use it.
Sometimes it seems like Linux people don't want others using it. Even when they belong to evangelist platforms, they like to create huge barriers for entry and then blame new users for not "getting it."
SELinux does better or worse, depending on perspective, by actually enforcing controls