101–110 of 461 posts
As an experienced RHEL admin, a few years ago I probably would have said this is very bad advice in any professional context, and you should spend the time to learn it because it will save you one day. Now, I think my advice would be: Put everything in a container, and learn how to run Docker or Podman (or k8s) in a secure way (ie no root containers, be very careful with volume mounts, etc). Yes, they aren’t as matur…
Hum, as another admin... No thanks. With IllumOS I can agree on zones, I can partially agree on lpar on AiX, I can accept GNU/Linux limits with cgroups. Enlarging the attack surface to follow the current wannabe Gurgle mania... No. Like no in the recent past to full-stack virtualization on x86 to enrich VMWare, buy big desktops sold as powerful servers just to play matryoshka doll for someone else business... Of cour…
I've always preferred apparmor. SELinux has always seemed radically more complex for very little benefit, unless you have a tightly constrained OS (like Android, where the VM does most of the work and every app has the same sort of security policy) or a team of admins working full time to maintain it (again, like Android). Apparmor is weak in all the same ways SELinux is weak, at least in terms of the ways that actua…
In case you have trouble, just install (setroubleshoot-server) and run sealert -a /var/log/audit/audit.log and it'll inform you whats needs to be done, i.e set a sebool or generate a policy. Solves 95% of the problems.
I have to say, for sysadmin work I find this view sorta overblown. My experience is with RHEL and derivatives, not Fedora, and for the most part those are very straightforward and while selling does rear it's head every once in a while, it's usually not that problematic to work around. When you have something failing that you need to fix and isn't an upstream problem (i.e. your own app or some third party vendor), yo…
In my experience creating and applying new policies with audit2allow is almost always the wrong thing to do. Most SELinux issues are either a SELinux boolean that needs enabling, or SELinux file type that needs changing. The few times where you do need to create new policies then audit2allow is useful but still requires you to review and understand the changes it's going to make before applying them.
I think that's very dependent on what you're doing, and how supported the thing your doing is by the OS. We write a lot of custom software. We also end up installing a lot of applications that didn't ship with good (or any) rulesets, or that we packaged into RPMs ourselves. Using audit2allow (after first checking audit2why and booleans) has become standard enough in those cases to generate a ruleset that makes sense (either for immediate installation or adding to a package we're building) that my experience seems to be somewhat different than yours. Or maybe we just run a lot more servers and while the percentages are the same the total numbers look higher, I don't know.
There's also the cases where we basically threw our hands up and said screw it, run in permissive mode indefinitely, because the alternative it too annoying and error prone (I'm looking at you, Jira).
> The few times where you do need to create new policies then audit2allow is useful but still requires you to review and understand the changes it's going to make before applying them.
Yep, and I noted that I don't think the audit logs and autdit2allow output aren't actually all that hard to understand if you take the time to look.
I would argue that no solution in and of itself is complete.
I hope someday we can get away from the idea that containerization is the complete solution.
I have been a system admin for over 20 years, and it seems we still have not been able to get the concepts of defense in depth, and specifically many layers of defense on each level to soak in.
I see multiple people espousing the belief (in the comments on this article at least) that containerization has solved this issue and SELinux is no longer needed.
I can think of a certain chaos goose (Ian Coldwater) who has been providing plenty of reasons why it's bad to trust containers alone for years.
In my personal experience SELinux has stopped attacks in their tracks when a 0 day hit, until a patch from upstream became available and is an invaluable tool for blue team in general.
It is not the most intuitive of tools, but most truly powerful tools are not intuitive, that seems to be a common trade off.
The gist of the problems is that the policies are not transparent (probably due to security reasons?) to the user/admin, did I get that right? And that there's a difference in enforcement between user policies and policies provided by the distribution? All this sounds to me like a good idea that got lost in the implementation. If you have no way to look up which policies are in effect and what is labeled and how, som…
There are tools to examine the policy, and you can get the source to the entire thing. Though it's rather big and complex, but it's certainly there.
The gist of the problems is that the policies are not transparent (probably due to security reasons?) to the user/admin, did I get that right? And that there's a difference in enforcement between user policies and policies provided by the distribution? All this sounds to me like a good idea that got lost in the implementation. If you have no way to look up which policies are in effect and what is labeled and how, som…
Yes.
> (probably due to security reasons?) to the user/admin, did I get that right?
No, that isn’t the reason. They’re open source. The policies are, simply put, compiled binary blobs from a comprehensive set of allow-rules and label-path definitions. The complexity of analyzing and difficulty in overriding these complex rulesets is the problem. There are tools for interacting with the system, but good luck figuring out what they’re even called. All the tools are optimized for the ruleset developers and not the sysadmins that have to play by the rules (and are never told what the rules are).
Answering the question, “What do I need to label files that should be read by program X?” is waaay to hard. You’re expected to put your files in certain locations and then some things work out-of-the-box. However, there’s no documentation on where you’re supposed to put the files.
Sure, /var/www is where you put your website files by convention. Apache can read from that directory. But what if you put it in /var/web? You can relabel the directory, but it’s not at all apperent why everything grinds to a halt when you do. The /var/www dir is owned and readable by the apache user, but Apache still says complains it can’t read it. That’s the SELinux MAC in action blocking you from doing something totally normal just because you didn’t follow the strict rulesets (that no one told you about).
Is the information being hidden intentionally to prevent attackers from gaining a toe-hold?
Red Hat is the Pinterest of Google searches for Linux problems. You’ll often find a page where someone is describing you problem but the resolution is locked behind a subscription login.