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

#411

Post by throwaway82652 » Wed, Apr 27, 2022, 6:29 PM UTC

4khilles wrote: post #407

_wldu wrote: post #181

I agree that SELinux is largely unusable in the real-world (especially for custom apps). I've had better experience with path based MACs like tomoyo and apparmor. Firejail is also great for end users who want to safely do online banking and surf the web at random on the same machine. IMPO, this sort of isolation is the future of endpoint security. Linux has seccomp (to filter syscalls), landlock (to limit filesystem…

Out of all the tools you mentioned, pledge and unveil are the most pleasant to use from a developer and operator's perspective. I'm hoping something something similar will arrive in Linux without it becoming xkcd 927.

The capability to do something like that already exists in Linux, just nobody bothers to implement it at the application level because pledge and unveil are actually just more terrible hacks and are only really suitable for packages that are built into the system. In real syadmin-land, nobody wants to recompile applications just to change some security settings.

Furthermore any of these things that are bolting more ACL or ACL-like restrictions onto Unix permissions are bound to eventually end up with the same problems as SELinux.

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

#412

Post by jandrusk » Wed, Apr 27, 2022, 6:31 PM UTC

The other thing is that not all sysadmins are security engineers and you essentially have to be one to be able to manage SELinux well. You really have to understand the security implications of incorporating policy X for application Y.

Minimally, Redhat needs to come up with some better documentation around managing it along with better tools for managing policy. Like say, exporting the existing policy set before each upgrade or policy change and import them back? I'm thinking sort of what is done when a package is updated and you are prompted if you want to keep or replace your existing configs.

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

#413

Post by throwaway82652 » Wed, Apr 27, 2022, 6:34 PM UTC

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…

>Also note that seccomp and landlock are very much different from pledge and unveil.

No, this is incorrect. They fundamentally do the same things. You're trying to say they're different because the API is different but that's completely missing the point. If you really prefer the API of them then you can go and use one of the emulations of pledge and unveil that have been built on top of seccomp and landock. They work because there isn't really anything special going on there.

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

#414

Post by greedo » Wed, Apr 27, 2022, 6:36 PM UTC

Spivak wrote: post #384

greedo wrote: post #354

Earlier quoted context omitted.

I'm actually agnostic as to how it's achieved. I just think that the idea of running a container for three months without patching the underlying OS is nuts. Generally our guys only redeploy a container when there's been an update, so that OS is pretty stale compared to what I'm running on traditional VMs. It really was more of a reflection on how DevOps can become too focused on application development and deploymen…

I kinda stopped worrying too much about it because the "OS" (really userspace) that lives in a container isn't in a position to be exploited like the underlying VM OS is. Nothing in the container is privileged and there are no security boundaries that exist within a container. You should care exactly as much about container image updates as you do gem/npm/pip updates and I guarantee you have months old deps pinned in…

So an application runs in a container that has a vulnerable OS. This has network access, DB access, NFS or SMB access. All valuable stuff. And then the container's OS gets breached due to the vulnerability. Sure, the VM hosting the Docker containers is secure, but that doesn't really matter if the breached container had access to PII or other valuable data.

This idea that people have about containers being 'the "OS (really userspace)' is fundamentally wrong. It's the equivalent of a VM, just (hopefully) stripped down to the bare essentials. There's no magic that protects it. The Docker host sure doesn't protect it, and in fact the Docker host can be vulnerable to exploitation from its containers, just as a vSphere host (or any other hypervisor) can be exploited if its VMs are insecure.

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

#415

Post by greedo » Wed, Apr 27, 2022, 6:43 PM UTC

_joel wrote: post #387

monkpit wrote: post #343

Earlier quoted context omitted.

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

If you're using an upstream image from a distro, pull that down, update it, push it back to a registry, then use that as your base image. Do that every day in a CI/CD (or just cron) system, such that you've got logs, auditing and fires off alerts if something breaks. Add update steps to the builds of your final image containers too at the start, to catch any delta that may have happened during last base image patch.…

Exactly what I've been trying to push to the team.

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

#416

Post by johnny22 » Wed, Apr 27, 2022, 6:47 PM UTC

htkibar wrote: post #397

vaylian wrote: post #341

Earlier quoted context omitted.

> Also your calculator app can read your sudo password as you type it True with X11. Fixed in Wayland.

Which is still not the standard - probably will take at least a decade before we can even talk about this issue being fixed.

standard or not, it's already shipping by default in ubuntu and fedora except for when nvidia drivers are involved.

The problems will be worked out.. one way or the other.

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

#417

Post by greedo » Wed, Apr 27, 2022, 6:48 PM UTC

xyzzy123 wrote: post #389

greedo wrote: post #332

Earlier quoted context omitted.

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.

If that matters why hasn't the internet exploded yet? Hardly anyone is doing that thing and it seems to not matter. People who panic only when they see $STUPIDLY_NAMED_ISSUE seem fine.

I work for a stodgy company with over $4B under management. In a highly regulated industry where you have to publicly announce breaches. Sure it may not matter to a quick startup where someone is re-inventing Uber for gokarts, or other small industries, but when you have to satisfy auditors and regulators across different jurisdictions, you can't take a laissez faire attitude towards patching and compliance.

And considering how many breaches occur on a weekly basis compromising customer PII etc, its foolhardy to say the Internet hasn't exploded yet. It's been in a continual burn for decades.

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

#418

Post by greedo » Wed, Apr 27, 2022, 6:52 PM UTC

icedchai wrote: post #408

xyzzy123 wrote: post #389

Earlier quoted context omitted.

If that matters why hasn't the internet exploded yet? Hardly anyone is doing that thing and it seems to not matter. People who panic only when they see $STUPIDLY_NAMED_ISSUE seem fine.

Unless there's a vulnerability in something internet facing, you can go a very long time without updating anything. So, yes, it doesn't matter... except when it does. I've logged into production systems with multi year uptimes, with updates that haven't been applied in just as long. Many orgs have a if it's not broke, don't fix it policy. Applying needless updates are just as likely to screw something up.

Many orgs get breached (or have no way to detect if they've been breached).

It depends on both your industry and your risk tolerance. We generally apply every security patch that comes along for RHEL. Application patching is different, it depends on the severity and what the vendor will support. If we can't patch, we try to apply compensating controls to mitigate the risk.

And the pride we all used to have with long uptimes is really a poor badge of courage. It shows a misplaced trust in either your security, or the threat model you face.

OS security patches (at least for RHEL) pose little risk of breaking applications. In the last 15 years, I've never once had to roll back a security patch from RH.

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

#419

Post by ethbr0 » Wed, Apr 27, 2022, 7:05 PM UTC

throw0101a wrote: post #360

ethbr0 wrote: post #269

Earlier quoted context omitted.

>> 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. Original comment misses two nuances with the gripe. 1. Container creators and software creators are not the same people. So they can (and should!) have different goals and priorities. For cont…

> 1. Container creators and software creators are not the same people. So they can (and should!) have different goals and priorities. For containers, security and reliability. For software, make it work. If the container system designers did their job properly it won't matter what the software does inside of it, as breakouts shouldn't be possible. It has been a few years since I looked, but last time I checked there…

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.

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

#420

Post by egberts1 » Wed, Apr 27, 2022, 7:07 PM UTC

tremon wrote: post #320

egberts1 wrote: post #163

Earlier quoted context omitted.

Right, right, and right. Even after mastering all the fundamentals of SELinux, six month later a different audit-related problem surfaced and “what was that command again?” This link often saves me: https://access.redhat.com/documentation/en-us/red_hat_enterp... In fact, I condensed it to the following steps (outlined elsewhere in this OP by patrck, new HN user): couple sysadm red flags: 1) The article author is Test…

The article author is Testing in PROD when you acknowledge this, then continuing your advice with setenforce 0 is a spectacularly bad idea. You can make individual domains permissive using semanage permissive -a ${context} and then run the failing test using only that permissive domain. Of course, the story becomes much more complicated if the failing test requires type transitions -- but blanket advising people to p…

agreed on all points. sometime the problem is so elusive that its flipping it to `0` time!