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

141–150 of 461 posts

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

#141

Post by devwastaken »

cnity wrote: post #136
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…

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

Wasm addresses memory and execution isolation from the rest of the system, however anything running in it maintains it's exploitable logic internally. If the application needs to read/write files, and someone exploits that logic, wasm won't help. The only thing that could is limiting the filesystem access in the first place and building secure software to begin with.

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

#142

Post by johannes1234321 »

Gigachad wrote: post #72
TheDong wrote: post #61

Earlier quoted context omitted.

> when you need to stay on bare metal What cases can linux containers not handle? Containers can access GPUs, /dev/kvm, block devices... I'm having trouble thinking of anything they can't do. After all, they're just processes in a glorified chroot, not that different from processes on the linux host.

Not sure about need but I do remember it being a pain in the ass to run anything that expects to be managing docker inside docker. Things like self hosted gitlab ci where its trying to start up containers itself.

Mounting the docker socket into a container works.

If it's advisable is another question, as that gives full control over all other containers (and likely more)

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

#143

Post by KronisLV »

bayindirh wrote: post #52

This is bad advice. SELinux might be hard, but it's neither unmanageable, nor it gets in your way when configured correctly. I've deployed both AppArmor and SELinux in high security environments, and they're nice layers of security to have. Yes, it has a learning curve, but it's worth it.

> Yes, it has a learning curve, but it's worth it.

That depends wholly on the circumstances in which those tradeoffs must be considered - additional security vs ease of use.

For people who don't work in banks and whatnot, the choice is probably rather simple to make, they'll just prefer to do whatever will let their code and software run as they want (be it permissive mode or disabling it).

In those circumstances, SELinux can be little more than a nuisance and a roadblock, something that they didn't ask for and don't want or care for.

When security is paramount, however, things are a bit different.

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

#144

Post by dijit »

cnity wrote: post #136
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…

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 files or shared memory.

The wheel keeps turning. Some new sandbox will come along.

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

#145

Post by Gigachad »

perryizgr8 wrote: post #115
Gigachad wrote: post #74

Earlier quoted context omitted.

It's free to set up. Justify why it can't be https.

Lots of things are free. Doesn't mean you need to do them. The burden of justification lies on the people advocating for adding complexity and dependency to a simple system.

It’s not complex. You click a button on GitHub. So gaining a decent amount of security and privacy easily justifies the work of clicking a button.

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

#146

Post by kaba0 »

cnity wrote: post #136
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…

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

Why would a completely new compilation target be needed for that when “old” sandboxes can work just fine by hijacking syscalls? Sure, memory safety is somewhat improved by Wasm, but valgrind and the like are effectively giving you the same thing.

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

#147

Post by froh »

porker wrote: post #128
zozbot234 wrote: post #85

Earlier quoted context omitted.

AppArmor is great. It can do much of what SELinux does, but it uses plain configuration files as opposed to incredibly obscure and clunky filesystem-level hacks.

It still has the same gotchas as a user though. I was daemonizing a uvicorn (Python) process using systemd and could not get the Python script to write its log file anywhere. Not the current directory owned by the user, not elsewhere, and no errors showing up in the system logs. After a few hours banging my head against the wall I discovered systemd's ReadWritePaths. Once I set that, it would log to any directory I s…

This is a selinux gotcha, not an apparmor one, right?

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

#148

Post by touisteur »

anonymousDan wrote: post #102
kkfx wrote: post #73

Earlier quoted context omitted.

Hum, as another admin... No thanks. With IllumOS I can agree on zones, I can partially agree on lpar on AiX, I can accept GNU/Linux limits with cgroups. Enlarging the attack surface to follow the current wannabe Gurgle mania... No. Like no in the recent past to full-stack virtualization on x86 to enrich VMWare, buy big desktops sold as powerful servers just to play matryoshka doll for someone else business... Of cour…

Can you elaborate on the scalability problems with infiniband?

I'm guessing part of the problem infiniband switches get expensive AF when you're going for 32x100 or rack-level anything. And you're still bound to up to 200Gbit per link (and the cpu load that entails) or lower bandwidth bonded links, why is not as interesting as QPI.

Aside from purely guessing I'm interested in scalability pains war stories with infiniband too :-) as I'm looking into a 400GbE-everywhere datacenter build...

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

#149

Post by CraigJPerry »

bitcharmer wrote: post #96
TheDong wrote: post #61

Earlier quoted context omitted.

> when you need to stay on bare metal What cases can linux containers not handle? Containers can access GPUs, /dev/kvm, block devices... I'm having trouble thinking of anything they can't do. After all, they're just processes in a glorified chroot, not that different from processes on the linux host.

Ultra-low latency applications on Linux are definitely one domain were containers are a big no-no for performance reasons. In my field (HFT) you won't find any serious performance-sensitive deployments using containers. So that's one example.

Are you referring to kube rather than containers?

A container is just namespaces and cgroups. You can still have your mellanox or solarflare zero-copy network stack for a containerised process.

That is, a containerised user space process can directly access the hardware, bypassing the kernel but isolated from other processes.

There are plenty of footguns for sure though but my experience working in HFT has been everyone is pretty elite skill-wise so sharp edges are not an issue in practice.

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

#150

Post by mikewarot »

Fundamental assumptions in the SELinux model (or in my understanding of it) * Every executable has only one role in the system. * That role does not change often * Every executable can be trusted, does what it says it does, and never gets confused * Fixed access control lists, security tags, are adequate in the 21st century.
Post reply on HN