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

301–310 of 461 posts

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

#301

Post by tremon »

someguydave wrote: post #253
goodpoint wrote: post #195

Earlier quoted context omitted.

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

How does static linking increase workload?

By multiplying the number of potentially-vulnerable copies of a library by the number of ways to detect the presence of said library and by the number of ways to upgrade said libraries when found.

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

#302

Post by dale_glass »

Asooka wrote: post #292
dale_glass wrote: post #152

Earlier quoted context omitted.

Some of the problem is that historically we've built systems badly engineered for security. Take for instance something like xscreensaver. Something in there needs to be setuid so that it can verify your password to unlock the screen. That something is fortunately a dedicated binary, and not every single screensaver, but still, that's bad. Writing that executable is a delicate thing. Get one of them wrong, and it's a…

What's the difference between a service that you send a string to and get a string back and a binary that you execute with a string argument and it prints a string argument back? I quite like the latter, as you're free from keeping state and thus have a smaller attack surface or potential to leak resources. Of course one difference is the execution environment, with a systemd service you can have it set up exactly as…

You said it yourself. LD_LIBRARY_PATH, and a myriad other knobs.

Think of all the stuff you can do: mess with filehandles, signal handlers, chroot, resource limits, seccomp, capabilities, program arguments... and more appear over time. You can't defend yourself from things that didn't exist at the time the code was written.

Polkit recently got exploited this way: https://blog.qualys.com/vulnerabilities-threat-research/2022...

Putting it on a socket is a good way to make sure the client has no control over the environment.

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

#303

Post by caymanjim »

paledot wrote: post #286
caymanjim wrote: post #281

Earlier quoted context omitted.

It's pragmatism. If something doesn't work, it doesn't matter how secure it is.

If something isn't secure, it doesn't work. At that point, you would've been better off shipping a wireframe.

A door with a broken lock still provides value. An online PDF converter on a website without SSL still provides value. I'm not saying security doesn't matter or that it shouldn't be a priority, but things don't need to be perfect to be useful. It makes sense to focus more on functionality than security in many areas. I host a bunch of web apps behind a firewall that aren't secure enough to expose to the public Internet. Even commercial ones.

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

#304

Post by loeg »

tristor wrote: post #282
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…

Honestly, the bigger issue is that most SWEs just aren’t very good. It’s extremely telling that when you spend time in tech forums most people dread system design questions as the harder side of interviewing for senior level SWE roles… System design, though, is the actual point of SW ENGINEERING. That’s the part that is responsible for creating a foundation of quality to build on. The other side is that sysadmins hav…

> It’s extremely telling that when you spend time in tech forums most people dread system design questions as the harder side of interviewing for senior level SWE roles…

> System design, though, is the actual point of SW ENGINEERING.

I mean, I would say I'm pretty good at engineering and system design (10 YoE, senior/principal for most of them). But I dread the system design interview questions because (in my experience) they bear almost no relation to the system design experience I have and almost no relation to the actual requirements of the job. Things like "design an ETL flow" or "build a distributed wikipedia downloader" are just not in my area of experience. (I work mostly in the lower layers of single-host operating systems and file systems.)

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

#305

Post by lazyier »

freeopinion wrote: post #293
lazyier wrote: post #280

Earlier quoted context omitted.

> 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. There are many many problems. One of the biggest problem with SELinux is that it is trying to graft Mandatory Access Controls on a userland that is not designed for it. Unix, frankly, is not designed for security. It is designed to get work done by writing a bunch of…

My android phone came without a calculator app. I recently realized this in a setting where I needed a calculator. I commented out loud about the lack of calculator and got some responses from the group I was in at the time. "Just download one from the app store," I was told. "But be prepared to grant it network access, file access, contacts access, camera access, and email privileges."

The alternative, which is Linux, is to grant your calculator app the permissions to read and write to the same resources that your browser uses to store the password for your bank.

Well "grant" is too strong of a word. "By default and there is nothing you can do about it unless you are exceptionally skilled" is more accurate.

Also your calculator app can read your sudo password as you type it, which you do a dozen times a day to carry out complex and security sensitive tasks such as "Connect to printer to print out mom's recipe for brownies" and "restart bluetooth because it's buggy and you want to listen to spotify on your wireless headphones".

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

#306

Post by fargle »

prmoustache wrote: post #98
fargle wrote: post #34

How can I trust some opaque policy I cannot see? Not just trust that it is well intentioned not evil, (Oracle Linux?), but that it does what it says. And does what I need and that the opaque developers have correctly envisioned what I need to do. Security by obscurity is worse than none at all. Security by buying an "Enterprise" product is worse than that. What SELinux says is " real MAC security is super complicated…

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

really? I don't mean understand how to apply a new label. I mean understand what the policies are and how they work, be able to create new ones that apply to you, and verify that the ones given to you by the distro are correct for your use. You're saying this is not hard to understand: https://github.com/SELinuxProject/refpolicy/blob/master/poli... ?

Otherwise you are blindly applying some black box.

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

#307

Post by rhines »

tristor wrote: post #282
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…

Honestly, the bigger issue is that most SWEs just aren’t very good. It’s extremely telling that when you spend time in tech forums most people dread system design questions as the harder side of interviewing for senior level SWE roles… System design, though, is the actual point of SW ENGINEERING. That’s the part that is responsible for creating a foundation of quality to build on. The other side is that sysadmins hav…

Maybe we're just in different circles, or perhaps have different definitions of system design, but that's not been my experience. Usually I see developers being very excited about system design and quite good at understanding system design questions - nothing's more fun than architecting a new system and thinking about stuff like scalability.

Where people tend to fail is when they have to implement these systems, and they've planned for all these high level building blocks but then actually have to configure them. Redis, RabbitMQ, GraphQL, Docker, NGINX, the list goes on - there's so much to configure and you really don't truly know how they work unless you dive into the source code, so you inevitably get bitten by subtle bugs and errors where your expectations of how something should work based on the docs are violated by how it actually works.

Should a SWE have a deep level understanding of all this stuff? I'm not sure. Usually you can still hack it into a working system after a little bit of firefighting, and that's likely more time efficient than understanding source code or rolling your own infrastructure. But I definitely think there's room for more comprehensive and transparent documentation to bridge the gap between the source code and barebones docs.

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

#308

Post by loeg »

throw0101a wrote: post #229
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. […] 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…

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

It's not just sysamins -- developers don't understand SELinux, either.

As a dev, I find least-privilege sandboxing (e.g., look at how sshd is structured) and capabilities (e.g. FreeBSD capsicum) somewhat non-intuitive, but at least tractable to understand. SELinux is a blackhole.

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

#309

Post by loeg »

staticassertion wrote: post #261
fefe23 wrote: post #194

Earlier quoted context omitted.

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…

How is the libc issue specific to linux? OpenBSD has a libc too.

OpenBSD doesn't support syscalls from alternative libcs, so you reliably get consistent syscall behavior.

But I believe GP is mostly talking about pledge(2), a pretty easy way to implement common sets of seccomp-like restrictions, and unveil(2), an easy way to limit path visibility. These are OpenBSD security features that Linux does not have direct equivalents of.

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

#310

Post by tremon »

josephcsible wrote: post #23

SELinux has a horrible misfeature called dontaudit, that lets policies using it deny actions without any evidence being logged anywhere. Because of the existence of this, the only reliable way to know if a problem is being caused by SELinux is to temporarily disable it and see if the problem goes away.

Not only that, but the official policies rely on dontaudit rules because there are known policy violations that are in fact harmless (like processes scanning entire directories, or attempting to open a file in various locations). So disabling dontaudit means your logs will get cluttered with non-related error messages that were up to then silently ignored.
Post reply on HN