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

201–210 of 461 posts

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

#201

Post by legulere »

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 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” for services is just a hack that tries to use an inadequate system as much as possible.

The Unix security model is deeply baked in everywhere and it’s nearly impossible to tack on a security model fitting to todays requirements afterwards.

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

#202

Post by dale_glass »

kelnos wrote: post #176
db48x wrote: post #140

Earlier quoted context omitted.

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…

How does this work when you want to log different things? Like if I had a web server, I wouldn't want the server log and access log to go to the same place. Sure, I guess I could send one to stdout and the other to stderr, but what if I have three things? Maybe systemd/journald supports this use case by forcing you to adopt some sort of structured log format that you emit to stdout, but I don't think I want to have t…

Journald indeed supports structured logging.

Try `journalctl -o json` to see all the fields that get logged. Applications can add more.

So it very much means that a webserver logging to journald can already provide it all with fields for the vhost, status, URL, referer, and whatnot, and you can just search the log by that and don't need to do your own parsing.

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

#203

Post by goodpoint »

fefe23 wrote: post #194
_wldu wrote: 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…

> Unless you have 100% test coverage (and if you had, why do you still need a sandbox then?)

100% test coverage does not guarantee absence of vulnerabilities in any way.

> 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.

Having sandboxed many things, this is plain false.

Normal applications and daemons have no reason to call reboot() or stime() and so on in any obscure code path.

If they do, the sandbox should stop them and that's a feature and not a bug.

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

#204

Post by elevader »

strzibny wrote: post #97

This is not a good advice. You'll basically get Ubuntu that didn't have SELinux in the first place, and most people don't care. SELinux is difficult to build from scratch but there are decent tools to build your policy in an automated fashion. The advice should be this: Don't have time to deal with SELinux at the moment? Switch to permissive policy and deal with it later. I included SELinux as one big chapter in my b…

That's not really great advice either, temporary solutions/workarounds have a tendency of sticking around permanently.

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

#205

Post by goodpoint »

mindwok wrote: post #2

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…

> but containers aim to provide many of the same benefits that SELinux does

Absolutely not. They are not designed as security tools in the first place. Especially docker, with its huge attack surface.

You are confusing containers with sandboxes.

Furthermore they don't implement anything resembling RBAC.

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

#206

Post by cassianoleal »

dijit wrote: post #144
cnity wrote: post #136

Earlier quoted context omitted.

This seems like something that WebAssembly (misnomer) is set to resolve, to some degree. Sandboxing capabilities is easy because all of the wasm module imports must be provided by the process that initializes the module, so you can view imports as a kind of list of "requests for capabilities".

I think that's leaning even more into the parents point. We make a sandbox (in this case a very inefficient one) -- we assume the sandbox is the only way to deploy software, but mostly it's not because there will be times you need more than the sandbox or the software doesn't work, and then you're running "privileged" WASM routines. The sandbox itself might even require some kind of leaky behaviour, such as accessing…

> and then you're running "privileged" WASM routines

That's pretty much where snap ended at, isn't it?

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

#207

Post by goodpoint »

seodisparate wrote: post #178
kaba0 wrote: post #159

Earlier quoted context omitted.

Convenience matter. Without it being automatically on everywhere , it doesn’t protect from much. Sure it can be good for the occasional random software you trust the least, but how many exploitable bugs were found in any of your completely trustable tools? Also, afaik firejail runs as suid, making any possible escape much more serious.

[1] discusses firejail running as root: > For a server, the process exposed to the outside world runs as an unprivileged user (unbound or nobody). The process is started by a separate process running as root (as explained by @Ferroin above). The starting process is never exposed to outside. > The same is true for Firejail. By the time the unprivileged server process starts, Firejail is already sleeping. And I think D…

Actually docker is much worse due to the large attack surface.

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

#209

Post by topdancing »

dale_glass wrote: post #63

I don't think I agree. I've been running things with SELinux enabled for more than a decade, haven't really had problems. The issue with SELinux is that it's security, and security is a complex issue that requires understanding what you're doing and why. It's not a problem domain that's friendly to the approach of poking at random until somehow things start working. It's not really different from filesystem permissio…

> Most of what they complain about have tooling, documentation and solutions. They're just not using them.

OP's problem is that they do not want to learn. In general - if you see a person complaining about SELinux - it's because they have no interest in learning.

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

#210

Post by dale_glass »

d2wa wrote: post #111
prmoustache wrote: post #98

Earlier quoted context omitted.

> but you can't understand it or change anything" That is not true. SELinux is not hard to understand nor change. Most of the issues you might encounter are simply solved by changing a label in a file or directory. It is just not straightforward to debug and understand if you don't know it is there. I think most people who complain about it are multi distros/OS users and just only realize after losing precious time t…

But what am I, as the sysadmin, supposed to label things? Even if I know that I probably need to apply some labels, how do I find out what the policies are? What labels can interact with this program? You can turn to Google and find some incantations in a blog or forum post from ten years ago, but you can‘t easily see which labels a program is allowed to interact with or not. (If you even know to ask that question.)

Fedora comes with manpages. So for instance, say you want to place http pages outside of /var/www. Fedora comes with the selinux-policy-doc package, which gives you the httpd_selinux manpage:

https://linux.die.net/man/8/httpd_selinux

It's a tad dense, but in the Sharing Files you can find a section explaining what context is used and for what. You can also look at the existing context, eg:

    $ ls -laZ /var/www
    total 4
    drwxr-xr-x.  4 root root system_u:object_r:httpd_sys_content_t:s0       33 mar 17 17:32 .
    drwxr-xr-x. 21 root root system_u:object_r:var_t:s0                   4096 abr 18 10:57 ..
    drwxr-xr-x.  2 root root system_u:object_r:httpd_sys_script_exec_t:s0    6 mar 17 17:32 cgi-bin
    drwxr-xr-x.  2 root root system_u:object_r:httpd_sys_content_t:s0        6 mar 17 17:32 html
And copy those for your own use.
Post reply on HN