Live data from Hacker News

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

ctrl.blog

341–350 of 461 posts

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

#341

Earlier quoted context omitted.

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

> Also your calculator app can read your sudo password as you type it

True with X11. Fixed in Wayland.

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

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

Docker actually comes with an apparmor config that disallows you to interact with any files outside of the container. It's not a so strong guarantee compares to inode based approach (selinix), but is still much better than don't have one. And if you enables uid mapping, your permission in the host system is just as high as nobody if there isn't a kernel exploit happened somewhere. But the fact it is nobody is also pr…

It comes with both an apparmor profile and an SELinux profile. What gets used depends on what's on the system... and I guess you need to actually set the flag on dockerd to enable SELinux.

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

#343
post #332

Earlier quoted context omitted.

I fully agree with your last point. In my experience, the all-versions-packaged approach of containers actually leads to a worse patch state than a simple Ubuntu or Debian installation with unattended-upgrades.

I've tried to explain to our Devops guys that they need to automate their patching so that a new container is fully patched before deployment. They had no idea what I was talking about. I said, "you have containers that run for months, right? And they aren't modified at all after deployment, right? So how do you address new vulnerabilities? How often are you patching your base image?" Just clueless looks.

How would you accomplish this exactly? Your use case may vary, but in my mind dependencies shouldn’t just be upgraded by some automated system without some sort of feedback mechanism (like tests).

If you’re going to run tests against the new dependencies, then why not just shift that whole activity to the development process itself (not the deployment system)?

When dependencies are sufficiently different from the existing prod dependencies, you can release a new version, instead of expecting ops/devops to take care of your dependencies for you.

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

#344

Operating system security was important back before VMs became cheap. At this point you are really wasting time if you invest significant effort in host security. It's the new network security. Separate concerns into VMs and network connections separated by strong authentication, authorization and encryption, and practice least privilege. It doesn't matter if your OS or containers are made of security swiss cheese as…

I’ve heard several high-level security engineers take this stance in organizations with stringent security requirements. There may be some truth here when prioritizing work, but I have yet to see strong authn/authz prevent red teams from wrecking havoc.

It’s too complex. We like to think of systems as being fairly constrained, but in practice I am not convinced that is true. Once you start adding other business functions to your environment, like observability, you can introduce non-obvious gaps in your policies.

Would having OS security completely prevent an attacker from wrecking havoc? Probably not. But it would make it much more difficult. It can also protect you from container/VM escapes.

Are SELinux policies complex? Yes, but they are constrained to a host’s system and are yet another layer of defense that can be used to secure software.

I’ve seen again and again how an SELinux policy can prevent an exploit from causing harm. It can also be an effective and quick way to mitigate risks from a new 0-day being posted while software teams work on patching.

I am fairly convinced, or bullish, that making SELinux easier to configure is a solvable problem. The biggest hurdle to it is this puzzling movement within security to avoid OS-level controls and instead focus on network-level controls. It puzzles me why a well-resourced org thinks you can only invest in one or the other.

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

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

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

Software Engineering is about problem solving using software and hardware (we'll just say computers for simplicity). Whatever solution system you propose has inherent constraints and tradeoffs. That's the Engineering. System design is a catchall phrase for a subjective problem scale.

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

#346
I used to be really grumpy about SELinux until I learned about audit2why and audit2how. With those two utilities SELinux is just as easy if not easier to configure than any systemd process.

Every job is hard when you are using the wrong tools. Don't change your oil with pliers, and don't setenforce 0.

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

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

It's the forward march of progress. As things get more complex they also get more fragile and inscrutable, and harder to solve problems for.

Containers are a reaction to the flaws in the system. Fixing the root cause of those flaws is hard, because they're systemic. We would need to re-design everything to fix those flaws. Containers are a stop-gap measure that makes things easier to deal with.

The thing that I've learned about systems is they are all crap, but humans constantly munge them to keep them working. We don't end up with the best systems, we end up with systems easiest to munge. Every once in a while, a spasm of collective organization redesigns the system, and then we keep going with that one. It's evolution. So however crap our current system is, eventually it will change, probably for the better. It just takes a really long time.

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

#348
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), 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…

a.k.a container.

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

#349

Longtime SA, constantly ribbed or outright insulted for my absolute hatred of SELinux. Yes, I just turn it off first thing. Well, used to when stuck with RHEL environments. If you want people to adopt and really use something at large, you need to make it simple, explain when and why it's useful, and document it well. SELinux doesn't do any of that particularly well. And now that most things are effectively running o…

Security can't be made simple. At the core what SELinux does is simply enforcing a policy. A list of "Should X do Y to Z?". This is something that can't be implemented with just file permissions. What SELinux does is sandboxing every process it controls. For instance, my cupsd is running as root. It's accepting connections on port 631. If it started accepting connections on port 22, that's probably a bad thing. If it…

Appreciate the detailed and thoughtful response.

That said, it seems like the more basic use cases can be accomplished more simply. For example, using capabilities and proper groups instead of running things as root has been the recommendation for a while now. In that scenario, cupsd would never be able to do much to the system if compromised in the first place.

A proper iptables/nftables default deny all incoming is pretty simple to setup, perhaps less so to maintain as services are added. I find the separation of concerns and maintenance a lot easier to reason about, ymmv.

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

#350
post #304

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…

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

In the real world, if I was tasked with "build a distrbuted wikipedia downloader" I wouldn't just start randomly guessing.

I'd get input, feedback, discuss, narrow down options.

Yet for some reason, that's an actual interview question. Start randomly guessing based on your knowledge of something, in a way that you'd never do in a real scenario.

Edit:

I feel like I should do an interview like this. Refuse to explain how to build it, and instead explain the detailed process on how I would successfully build and complete the project. lol

Post reply on HN