Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

ctrl.blog

Post reply on HN
Print view View original

191–200 of 461 posts

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

#191

Post by bayindirh »

KronisLV wrote: post #162
bayindirh wrote: post #158

Earlier quoted context omitted.

> That depends wholly on the circumstances in which those tradeoffs must be considered - additional security vs ease of use. Of course, horses for courses. That's always implied, and I always keep that in mind. However, if there's a case which needs that level of security, telling "Nah, just disable it, we'll do containers instead" is wrong at best, very dangerous at worst. Also, I find having a background knowledge…

> However, if there's a case which needs that level of security, telling "Nah, just disable it, we'll do containers instead" is wrong at best, very dangerous at worst. Agreed, though partially. Those two technologies don't have to be mutually exclusive, though they sometimes are considered to be (e.g. working around the "system limitations" by using containers, when both could work in unison). There are cases where y…

> Agreed, though partially. Those two technologies don't have to be mutually exclusive.

No, of course. I only objected using containers instead of SELinux / AppArmor. I don't consider containers as "Security Layer" per se. The situation is just a side effect in my eyes, and if you need proper security, you need proper hardening. Solely and blindly trusting secondary effects for security is wrong and dangerous.

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

#192

Post by zozbot234 »

chr15p wrote: post #187
zozbot234 wrote: post #85

Earlier quoted context omitted.

AppArmor is great. It can do much of what SELinux does, but it uses plain configuration files as opposed to incredibly obscure and clunky filesystem-level hacks.

AppArmour assumes everything is allowed unless it is explicitly denied by policy, SELinux assumes everything is banned unless it is allowed by policy. This makes SELinux fundamentally more secure because unlike apparmour you cant forget to deny some access that leaves you wide open, instead you forget to allow things and your app breaks. It also makes SELinux more complicated to implement because you have to allow ev…

> AppArmour assumes everything is allowed unless it is explicitly denied by policy

No, AppArmor uses a whitelist approach as well for its profiles. "Deny" rules are used in exceptional cases.

> SELinux also supports interesting things like applying security levels and contexts to data, so you can have data that is only accessible to appropriatly cleared users in one department but not to people with similar clearances in other departments.

AppArmor has subprofiles and variables that can be used for this approach.

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

#193

Post by emmelaich »

jandrese wrote: post #4

> There’s nowhere on the system where you can view the policies and look up why something might or might not work. I always thought I had to be missing something with SELinux because this is what it seemed like to me and that can't be right. My impression is that the documentation for SELinux is extensive in all of the areas that aren't affecting you but it's really hard to nail down exactly what the policies are, wh…

You can install the policy source. It ain't easy but it's there.

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

#194

Post by fefe23 »

_wldu wrote: post #184
ptidhomme wrote: post #153

Earlier quoted context omitted.

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? This almost looks like a hint to OpenBSD's pledge and unveil system calls. I'm just a hobbyist, but regarding we all run software we don't understand what I like (again) in OpenBSD is that I feel I can largely understand/control what's happening in my system, it quite f…

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, or mmap, and maybe also munmap. If you hit an error, it will also call write to output an error message to stderr.

dietlibc will do open, stat, mmap.

This is also libc version dependent!

But can you at least use strace to know which files will be opened? No, not even that! Because the code may open some files only under certain circumstances. For example, localtime will open /etc/localtime -- but then it will cache the result for a while. /etc/localtime may be a symlink. If you construct a container you would also need the thing it points to.

What if you use a malloc that has explicit hugepage support?

Also note that seccomp and landlock are very much different from pledge and unveil. I am particularly appalled by landlock as compared to unveil. Go look up the landlock API if you don't believe me, and compare it to the unveil man page. If you thought the hoops seccomp makes you jump through are ridiculous, you haven't seen anything yet.

OpenBSD is not all gold either. pledge is not transitive. If your process pledges something but is allowed to execve something else, the process you exec is not bound by your pledge.

There is MUCH room for improvement all around.

However, the persisting idea that you can use a "training mode" or observe via strace to construct a whitelist IS WRONG and dangerously so. Unless you have 100% test coverage (and if you had, why do you still need a sandbox then?) you will miss error handling and optional code paths that you didn't enable in the configuration, and handling code for circumstances you didn't trigger and didn't foresee.

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

#195

Post by goodpoint »

fefe23 wrote: 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

Reminder: containers are not meant to be security tools.

Fine-grained sandboxing (e.g. seccomp) is. And it can be layered upon OS-level VMs.

Additionally, bundling tons of stuff together with an application (like docker but also flatpak do) is not good for security. Same for static linking. They all increase the workload of updating vulnerable dependencies.

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

#196

Post by nix23 »

koffiezet wrote: post #131
scrapheap wrote: post #62

Earlier quoted context omitted.

Sysadmin Rule #1 - Is it SELinux? Sysadmin Rule #2 - Is it systemd? Sysadmin Rule #3 - Have you checked the logs?

Where's the time where you could just assume it was DNS.

And Time..ntp etc.... ;)

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

#197

Post by porker »

froh wrote: post #147
porker wrote: post #128

Earlier quoted context omitted.

It still has the same gotchas as a user though. I was daemonizing a uvicorn (Python) process using systemd and could not get the Python script to write its log file anywhere. Not the current directory owned by the user, not elsewhere, and no errors showing up in the system logs. After a few hours banging my head against the wall I discovered systemd's ReadWritePaths. Once I set that, it would log to any directory I s…

This is a selinux gotcha, not an apparmor one, right?

No, this is happening with apparmor on an Ubuntu 20.04 server.

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

#198

Post by geraldwhen »

megous wrote: post #122
bitcharmer wrote: post #96

Earlier quoted context omitted.

Ultra-low latency applications on Linux are definitely one domain were containers are a big no-no for performance reasons. In my field (HFT) you won't find any serious performance-sensitive deployments using containers. So that's one example.

Why would a container increase latency? It's just a pointer on a process. It's there on all processes. https://elixir.bootlin.com/linux/latest/source/include/linux...

https://www.diva-portal.org/smash/get/diva2:1252694/FULLTEXT...

Also docker NAT will add significant latency if you don’t use host network mode.

When microseconds matter, everything matters. Any intermediate program would be suspect.

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

#199

Post by porker »

db48x wrote: post #140
porker wrote: post #128

Earlier quoted context omitted.

It still has the same gotchas as a user though. I was daemonizing a uvicorn (Python) process using systemd and could not get the Python script to write its log file anywhere. Not the current directory owned by the user, not elsewhere, and no errors showing up in the system logs. After a few hours banging my head against the wall I discovered systemd's ReadWritePaths. Once I set that, it would log to any directory I s…

Most systemd services log to stdout and let systemd put it in the journal, or they log to syslog and let systemd put it in the journal. Most don’t write their own log files any more. I really recommend going that route because it is nice to be able to search the journal, especially if you provide extra metadata for each log message. It sounds like you were using the DynamicUser=, ProtectSystem=, or ProtectHome= setti…

> It sounds like you were using the DynamicUser=, ProtectSystem=, or ProtectHome= settings which can greatly limit where a service is allowed to read from and write to

Thank you! I have DynamicUser set - I can't think why I added it here, perhaps no reason at all - and that is the difference to previous systemd services I've written. I did not know it had such an effect on behavior.

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

#200

Post by chr15p »

jandrese wrote: post #4

> There’s nowhere on the system where you can view the policies and look up why something might or might not work. I always thought I had to be missing something with SELinux because this is what it seemed like to me and that can't be right. My impression is that the documentation for SELinux is extensive in all of the areas that aren't affecting you but it's really hard to nail down exactly what the policies are, wh…

sesearch lets you query the rules on a system.

sesearch -A will show you every thing that is allowed, and gives you (a lot of) lines like:

allow httpd_t httpd_t:dir { getattr ioctl lock open read search };

Which says that things (i.e. processes) with the httpd_t label are allowed to perform getattr, ioctl, lock, open, read, and search operations on directories with the httpd_t label.

ps -Z and ls -Z will then list the labels of processes, and the labels of files and directories. If your processes label does not have an allow rule for your file label for the correct action you are denied.

The only trick really is that when it reports a label as say "system_u:system_r:httpd_t:s0" thats 4 different colon separated fields and the only one you really care about is the type field "httpd_t", because thats what the rules are defined for (unless you're the NSA or doing Very Interesting things (the other fields are user, role, and security level, but the default Red Hat etc selinux policies dont use them))

There is no wiki with definitive list of labels because they are just strings and the policy writer can call them what they like, even the _t suffix is just a convention to denote the type.

Post reply on HN