SELinux is unmanageable; just turn it off if it gets in your way • Hacker News Board

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

#431

Post by ethbr0 » Wed, Apr 27, 2022, 9:46 PM UTC

throw0101a wrote: post #423

ethbr0 wrote: post #419

Earlier quoted context omitted.

One side has a huge footprint to secure (software-system), because it's every way software could ever need to interact with a local system. The other can expose a much smaller one (container-system), because it only needs to include things one would have gone off-local-machine for (i.e. networking). So from a security boundary, containers are basically a machine-internal firewall between programs and the host.

> So from a security boundary, containers are basically a machine-internal firewall between programs and the host. Which is only useful if they actually provide security.

You're missing my point.

It's effectively impossible to ever provide security at the program-system interface, due to the surface area. (I.e. the SELinux problem)

The very concept of having a container (that internally simulates a system) creates fundamentally different opportunities that allow both (programs that work) and (security).

Whinging about whether or not current containers do a good or bad job of it is a less interesting, short term quibble.

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

#432

Post by lucideer » Wed, Apr 27, 2022, 9:50 PM UTC

jitl wrote: post #270

lucideer wrote: post #255

Earlier quoted context omitted.

> The problem is not so much that selinux is too complicated (it is as complicated as it needs to be) I disagree. > but that we all run software we don't understand. I fully agree. My disagreement lies in the fact that you've described the problem, but are proposing that some software (SELinux) that fails to solve the problem is somehow good. SELinux might be a perfect tool in an ideal utopia where everyone understan…

SELinux is applicable in the real world, but you must choose if you want it to be Fast (use globs of rules written by unknown people who don’t know your requirements), Cheap (start from zero and develop policies specifically for your app), or Good (do both while learning a substantial amount about SELinux). If you’re using SELinux rules off the shelf for a handful of Fedora boxes for personal use, maybe that use case…

I think what people are missing (and perhaps the author is at fault for not calling this out more explicitly), is that the complaint is effectively: SELinux is more difficult to configure than it needs to be / should reasonably be.

Perhaps due to unnecessary internal architectural complexity, the lack of a good configuration interface, and/or bad config docs (which of these is the biggest culprit I'm not sure, but they all seem to have some level of truth to them).

The gp posited that it's necessarily complex - subjective, but I don't buy it. The author provides a good selection of examples that seem straightforwardly non-sensical in their operation: why doesn't audit2allow integrate properly with the overall SELinux architecture instead of requiring separate knowledge of semodule for application. Why doesn't the system keep track of label deprecation as system dependencies are changed & updated? These seem like pretty obvious out-of-the-box basics you would design in, if SELinux had been "designed", but the answer to these questions seems likely to be that it's more of a bundle of un-integrated tools and loose-text configs/blobs without well-thought-through centrally architected database of labels, maps and APIs.

One could even take this blogpost as a constructive set of ideas to improve SELinux, but the scale of the issues do seem overwhelming to change on such a large project, and based on the comments here on HN there seems little will to do so. To the point that perhaps a separate / new approach would be easier.

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

#433

Post by derefr » Wed, Apr 27, 2022, 11:11 PM UTC

lucideer wrote: post #255

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 not so much that selinux is too complicated (it is as complicated as it needs to be) I disagree. > but that we all run software we don't understand. I fully agree. My disagreement lies in the fact that you've described the problem, but are proposing that some software (SELinux) that fails to solve the problem is somehow good. SELinux might be a perfect tool in an ideal utopia where everyone understan…

SELinux is a perfect tool in its niche — where that niche is "secure-installation system integrators." It's not a tool for regular people; it's for e.g. defense subcontractors who want to certify their virtual appliance as meeting certain standards demanded by certain customers; where meeting those standards requires them to actually go through their virtual appliance from top to bottom and prove the whole thing secure and sandboxed.

It's not a tool for application developers (who at most can supply SELinux templates to start with); nor is it a tool for sysadmins (who really don't have the time or the incentives to deal with it.) It's a tool to be wielded specifically by people occupying a role that, in most organizations, doesn't exist.

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

#434

Post by gitgud » Wed, Apr 27, 2022, 11:16 PM UTC

tremon wrote: post #295

gitgud wrote: post #254

Earlier quoted context omitted.

> " The problem is not so much that selinux is too complicated (it is as complicated as it needs to be)... " Completely disagree, if the target users are advising each other to disable it... then the tool is definitely more complicated than it needs to be. Using tools that don't hide any complexity are very painful to use. It feels like the creator doesn't care about the user and put no thought into the display of in…

if the target users are advising each other to disable it... then the tool is definitely more complicated than it needs to be. This does not follow. I you ask a 5-year to repaint the Sistine Chapel and the result is somehow less than stellar, are you similarly going to blame the paintbrushes used? There exists no situation where the task at hand is too complicated for the user?

A better version of your example would be a 5-year-old that cannot open the packaging to get to the pieces of the paintbrush that need to be assembled, in order to paint his first stroke... that's the (arguably) unneeded complexity of SELinux

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

#435

Post by Asooka » Wed, Apr 27, 2022, 11:27 PM UTC

dale_glass wrote: post #302

Asooka wrote: post #292

Earlier quoted context omitted.

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

Yeah but that means we need to have a way of securely running binaries, not move a simple program to a service. Something like taking a snapshot of the system at various stages during init and have the binary start in a known context. This would also help a lot for desktop users - many programs need to start in a specific environment and having the option to configure per-user per-program launch environment would help a lot.

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

#436

Post by steelframe » Thu, Apr 28, 2022, 1:52 AM UTC

api wrote: post #318

steelframe wrote: post #285

Earlier quoted context omitted.

"We have an isolation problem. Let's use a VM!" Congratulations, you have just introduced an L1TF attack surface, and the bad guys are now freely reading all physical memory.

You have traded an absolutely enormous attack surface of hundreds of syscalls and a whole system full of files and apps for a much narrower attack surface involving the CPU and whatever the hypervisor exposes which can just be virtio-style pseudo-devices. Besides if the CPU is vulnerable than regular apps can probably exploit it too. Also I didn't say the best approach would necessarily be hardware VMs, though that i…

I hear a lot of, "Let's solve isolation with VMs," without taking into consideration that if you put two fully-patched kernels side-by-side, very few people (i.e., only those sitting on 0-days) have any idea how to exploit the workload running directly on the fully-patched kernel, while everyone knows how to exploit the (Intel) host when they have root/CAP_SYS_ADMIN in the VM and the host has HT enabled.

VMs are far from magic security sauce, and especially if you need HT on Intel hosts, you actively want to avoid using VMs as a "security boundary." You're far better off with the attack surface of a fully-patched OS image from a reputable vendor.

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

#437

Post by kcb » Thu, Apr 28, 2022, 2:38 AM UTC

rhines wrote: post #307

tristor wrote: post #282

Earlier quoted context omitted.

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…

Agree completely. I've never known a software engineer who didn't love designing new systems on paper and starting the initial development. It's when it comes time to stabilize and turn a system into a usable product minds quickly wander to designing the next system that fixes the flaws of the last system.

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

#438

Post by tadfisher » Thu, Apr 28, 2022, 3:06 AM UTC

ximm wrote: post #364

tinco wrote: post #235

Earlier quoted context omitted.

In my opinion, if an application requires more access than a docker container gives by default, then that application should probably just run in a VM. If the application needs more access because it needs to manage or control some hardware, then it should be tailored to the O/S and have a small core service that runs naked under systemd or whatever. If fancy management of that core service is needed, it can expose a…

What about an application like vim? It should be able to access any file I pass that is explicitly opened, but not much more. That is hard to express with current tooling.

You are describing the Flatpak security model. Flatpak was invented for interactive applications like this.

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

#439

Post by BenjiWiebe » Thu, Apr 28, 2022, 3:44 AM UTC

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

That is quite an exaggeration. My calculator app has requested 0 permissions. That's right, none.

Even though I use the calculator app from a famous ad company that loves gathering data - Google.

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

#440

Post by josephg » Thu, Apr 28, 2022, 4:11 AM UTC

perryizgr8 wrote: post #231

Hikikomori wrote: post #129

Earlier quoted context omitted.

>Sounds like an ISP problem. Buy service from a better one. No need to impose SSL on the website for this. Just move I guess.

Or don't. It's not a problem that needs to be solved server-side.

It is a problem to solve over the wire, because we should assume at this point that bytes over the internet are monitored. Both in the east (Great Firewall of China) and the west (NSA + Snowden). I don't want my ISP or my government knowing which websites I'm visiting, what apps I open on my phone or, really anything else about me without a court order. Insecure-by-default is a bad default.

To protect users, traffic over the internet should always be encrypted. Even if you don't care, as a user I care. And thankfully the people in charge of our software, protocols and ecosystem are slowly forcing the issue on our behalf:

- Unencrypted http will eventually be deprecated from web browsers. (Newer browser features are already banned in insecure contexts).

- iOS forbids applications from making unencrypted HTTP connections.

- The IETF more or less requires new protocols to be secure.

We'll see more of this over time. Its a good thing. Get on board.