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

331–340 of 461 posts

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

#331

Post by vaylian »

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…

SRE = Site reliability engineer?

SWE = Software Engineer (obviously)

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

#332

Post by greedo »

Sebb767 wrote: post #298
icedchai wrote: post #277

Earlier quoted context omitted.

Containers are more like a trash bag. Nobody expects it to be air tight, just good enough to make it to the dumpster. I always felt containers were always about packaging and deployment, not security. Any "security" was a byproduct of isolation, not an end goal.

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.

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

#333

Post by beached_whale »

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…

I view the container movement as a way of managing interactions. It’s really hard to manage dependencies in such a heterogenous systems. Containers simplify it all, at the cost of owning ones full dep tree. But with a good release process, one can keep on top of that and put less effort into the combinatorial growth when interacting with all the other dependencies other programs require.

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

#334

Post by Koffiepoeder »

KronisLV wrote: post #132
Gigachad wrote: post #72

Earlier quoted context omitted.

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.

> ...anything that expects to be managing docker inside docker. Now that's an interesting problem to have! If you trust those tools and don't have untrusted users or untrusted code, you can sometimes just mount /var/run/docker.sock and use the VM/VPS/server's Docker directly. It is actually the approach that was used by excellent tools like Portainer, though it's also really risky as well. Alternatively, you can try…

One project in this space that looked quite promising to me is sysbox[0]. I've used them once for a gitlab runner set-up similar to what is described in their blog[1].

It's currently working great and I have not had any major crashes/incidents for at least the past 8 months.

[0]: https://github.com/nestybox/sysbox

[1]: https://blog.nestybox.com/2020/10/21/gitlab-dind.html

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

#335

Post by someguydave »

goodpoint wrote: post #330
tremon wrote: post #301

Earlier quoted context omitted.

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.

Plus, it makes updating an application way more difficult: you need: - the distribution to recompile and test all binaries using a vulnerable dependency [x] - users to download and update all affected binaries compared to: - the distribution patching a single package - users updating that package Imagine if OpenSSL was statically linked: even the smallest fix would require users to update half of the OS. And that wou…

Why would you need to rebuild everywhere? Couldn’t you rebuild once in a trusted place and distribute signed binaries?

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

#336

Post by someguydave »

tremon wrote: post #301
someguydave wrote: post #253

Earlier quoted context omitted.

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.

What if your vendor was responsible for the fix?

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

#337

Post by rbanffy »

mindwok wrote: 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…

> much easier to manage

I would say it's not necessarily easier to manage, but it's much easier to understand, because containers create natural borders between the different software running on the machine.

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

#338

Post by bedast »

I did my RHCE bootcamp back when RHEL 5 was just released and the bootcamp course materials were not yet updated for it. The instructor worked around this pretty well. One of the earlier topics was SELinux, where he stated we would cover it for the course, but it's not on the certification exam and it's not needed past that part of the course, so we would disable it once we were done with the lesson. It's been well over a decade so I don't remember if this was day 1 or 2 of a 5 day boot camp.

Disabling SELinux and implementing more manageable controls has been a default for me for quite a long time, even before my certification. My preference is for apparmor, to be honest.

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

#339

Post by tremon »

someguydave wrote: post #336
tremon wrote: post #301

Earlier quoted context omitted.

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.

What if your vendor was responsible for the fix?

Then it increases the workload of said vendor?

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

#340

Post by greedo »

throw0101a wrote: post #283
A4ET8a8uTh0 wrote: post #262

Earlier quoted context omitted.

Huh? Compared to what exactly? Man-pages compared to MS provided info are fairly exhaustive.. Now if we are talking of a documentation of a random project on github..

The BSDs. When I admined Solaris there was also very good docs. The man depend on the utility. Except for the GNU stuff, where the man pages often tell you to look at the info pages.

Growing up on FBSD, it was quite the shock when I started working with RHEL/Debian. The qualitative difference between the manpages was disturbing.
Post reply on HN