Live data from Hacker News

SELinux is unmanageable; just turn it off if it gets in your way

ctrl.blog

221–230 of 461 posts

Re: SELinux is unmanageable; just turn it off if it gets in your way

#221
The Linux security space is pretty screwed up in general.

E.g. seccomp is pretty much unusable: https://blog.habets.se/2022/03/seccomp-unsafe-at-any-speed.h...

Another post of mine about how to drop privileges in Linux, and how hard it is: https://blog.habets.se/2022/03/Dropping-privileges.html

I've started writing a library for dropping privs (as if that should even be necessary), but the devil is in the details, so I've not pushed the code yet.

The beginnings of it is here: https://github.com/ThomasHabets/libdropprivs

Re: SELinux is unmanageable; just turn it off if it gets in your way

#222
post #134

The problem is not so much that selinux is too complicated (it is as complicated as it needs to be), but that we all run software we don't understand. The whole IT ecosystem has become a hail mary. Even admins usually have no idea what a certain program actually wants to do. If the admin knows how to install the app so that it actually runs, you call them a good admin. From a security point of view, an application is…

I've been recently thinking along similar lines about libraries. In web dev, it's common practice when you have a problem to first look for a library that solves it for you.

I get the "don't reinvent the wheel" sentiment but, I think we take it too far sometimes. I've been looking at the source code for some dependencies at work lately, and many of them actually don't hold up to our own code quality standards. Kind of subjective, yes, but many of our dependencies would probably fail code review if actually reviewed by us.

Then when there is a bug in a dependency, nobody actually understands how it works and the code is often tucked away and not easily changed.

Re: SELinux is unmanageable; just turn it off if it gets in your way

#223
Eh, what? SElinux is completely manageble and usable. I've been happily living with it for a long time. Now when I have to live with apparmor (which is exactly unmanageble) I really miss SElinux and really don't feel any secure without it.

Another wave of excuses in the manner of "i don't wanna learn anything".

Re: SELinux is unmanageable; just turn it off if it gets in your way

#224

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…

IMHO most RedHat systems tend to be overengineered. Even the config file split is overengineered in RedHat compared to many other distros. And documentation, although existing, tends not to be detailed enough to understand how to deal with the systems. You need trial and error.

Well, unnecessary complexity full of YAGNI is exactly what the E in RHEL stands for. Red Hat products need to be complex enough so that somebody will pay for support. :)

Re: SELinux is unmanageable; just turn it off if it gets in your way

#225
post #134

The problem is not so much that selinux is too complicated (it is as complicated as it needs to be), but that we all run software we don't understand. The whole IT ecosystem has become a hail mary. Even admins usually have no idea what a certain program actually wants to do. If the admin knows how to install the app so that it actually runs, you call them a good admin. From a security point of view, an application is…

The problem is that we have built all our software on Unix. The Unix security model is based on an attack model where users have to be protected from each other on a terminal server. Code is implicitly trusted and exploits were an unknown unknown. That security model is almost completely useless now. Terminal servers are an extreme edge case. Services implement their own security model between users. Special “Users”…

Is Windows much better with its VMS legacy kernel? It has a complex permission model with ACLs and everything but that trades inadequate permissions for something like the SELinux problem. There are too many knobs. (For this discussion leave aside the backward compatibility baggage which is another issue.)

The only approach that I see as viable without rebuilding the entire compute universe is VMs, either the web browser (JS and WASM sandboxes) approach or the qubes type approach.

Re: SELinux is unmanageable; just turn it off if it gets in your way

#226

Basically linux is moving from a hobbyist operating system that a single person can reasonably manage in their spare time to an enterprise ish complex monstruosity that requires training and a time investment. Probably because the main Linux sponsors have found that it's the only way to make money with it. SELinux... systemd... who knows what's coming next. Let's not forget ipv6, although that's not a linux specific…

As a Desktop environment, major Linux distros have never been as well polished as they currently are. It's gotten to a point that regular people can use them without much hassle.

From a sysadmin perspective,one always needed to invest time in Linux to be proficient in it, I don't see how that has changed greatly.

Re: SELinux is unmanageable; just turn it off if it gets in your way

#227
post #134

The problem is not so much that selinux is too complicated (it is as complicated as it needs to be), but that we all run software we don't understand. The whole IT ecosystem has become a hail mary. Even admins usually have no idea what a certain program actually wants to do. If the admin knows how to install the app so that it actually runs, you call them a good admin. From a security point of view, an application is…

I've been recently thinking along similar lines about libraries. In web dev, it's common practice when you have a problem to first look for a library that solves it for you. I get the "don't reinvent the wheel" sentiment but, I think we take it too far sometimes. I've been looking at the source code for some dependencies at work lately, and many of them actually don't hold up to our own code quality standards. Kind o…

when it comes to JS libraries I'm usually a lot more interested in how good their testing is. Code quality can be very subjective in some areas. But if the dang library doesn't have a lot of good testing then I can't really trust any updates from it :/

Re: SELinux is unmanageable; just turn it off if it gets in your way

#228
post #134

The problem is not so much that selinux is too complicated (it is as complicated as it needs to be), but that we all run software we don't understand. The whole IT ecosystem has become a hail mary. Even admins usually have no idea what a certain program actually wants to do. If the admin knows how to install the app so that it actually runs, you call them a good admin. From a security point of view, an application is…

Single page of instructions from google apps has me download a tarball, add a hello world command, and Presto! I have a webapp on my computer! Then change this one line and PRESTO! My webapp is in the cloud!!

No telling how, or with what components, or what the dependencies or security implications are, or how to see the logging for the app. Just a single paragraph of instructions and you can be the next internet startup IPO!

'Hail Mary' is the best way to describe the situation I've yet heard.

Re: SELinux is unmanageable; just turn it off if it gets in your way

#229
post #134

The problem is not so much that selinux is too complicated (it is as complicated as it needs to be), but that we all run software we don't understand. The whole IT ecosystem has become a hail mary. Even admins usually have no idea what a certain program actually wants to do. If the admin knows how to install the app so that it actually runs, you call them a good admin. From a security point of view, an application is…

> The whole container movement can be seen as putting the apps in a sarcophagus like Chernobyl. […] Who is responsible that it is air tight? Well, uh, nobody, really.

The people who designed the container/sarcophagus system. If it's not secure don't sell it as secure: see the difference between Linux containers and FreeBSD jails or Solaris zones.

> You can't even blame the applications for that. Let's say you want to build a good, secure application. How do you know what files your application will try to open? What syscalls it wants to call? Library and framework functions tend to not document that properly.

As a developer / software "engineer" it is your responsibility to know how the components you choose work and how much you can rely on them. When a structural engineer selects certain types of steel or concrete to be used in the construction of a bridge, it is their responsibility to know the characteristics of the raw materials.

When you ship a software product, enable SELinux or AppArmor and audit what it does: then ship an SELinux/AppArmor profiles.

See also OpenBSD's pledge(2) framework where the developer embeds system calls in their (C) code to promise to only access certain OS features:

* https://awesomekling.github.io/pledge-and-unveil-in-Serenity...

* https://man.openbsd.org/pledge.2

Re: SELinux is unmanageable; just turn it off if it gets in your way

#230
post #194
post #184

Earlier quoted context omitted.

You can use strace to get this information. Linux also offers seccomp and landlock which are very similar to pledge and unveil.

I would like to emphatically point out that: no, you can't. You can't use strace to get this information. Let's say you want to use seccomp to whitelist allowed syscalls. Your code opens a file, uses stat to get the file size, then mallocs that many bytes and reads the file contents into the buffer. Trivial program, right? glibc will turn open into openat, stat into statx, malloc can become either nothing, or sbrk, o…

Docker actually comes with a seccomp and an apparmor config that bans many things by default. while it is absolutely not noticeable unless you are trying something like docker in docker. There are so many syscall that shouldn't even be relevant to normal programs.
Post reply on HN