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

421–430 of 461 posts

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

#421

Post by freeopinion »

lazyier wrote: post #305
freeopinion wrote: post #293

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…

Oh, I agree. I'm just noting that access controls are useless in a culture that ignores them. I think that goes for the original topic of SELinux.

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

#422

Post by Spivak »

greedo wrote: post #414
Spivak wrote: post #384

Earlier quoted context omitted.

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

> And then the container's OS gets breached

This can't happen. There is no "OS" actually running. It's a bunch of binaries and files sitting in a tar archive that the process running can access and link against. What are you going to breach? All the networking, firewalls, kernel, remote access like SSH, and privilege management is the hosts. The only process running in the container is the application.

What you mean is "what if the application running in the container is compromised?" For example what if there's a RCE vuln in the version of libcurl that the app links against? Absolutely! Now you've got a huge problem but this is exactly the same as if there was an RCE in leftPad. In container world that's now the developer's problem instead of yours. Everything in the container is vendored, just pretend it was all statically linked. It's not like an VM where ops patches it.

> It's the equivalent of a VM, just (hopefully) stripped down to the bare essentials

No, no 1000 times no. It's in all ways the equivalent of a process (or tree of processes) running on the host machine. From a security perspective a container is no different than any other binary running on the host. You have it exactly right, there is exactly zero magic and no inherent security.

You should lose exactly as much sleep over outdated container images as you lose over outdated rubygems in your developers' Bundle.lock. Whether that means a lot or a little depends on the company and how security critical the application is.

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

#423

Post by throw0101a »

ethbr0 wrote: post #419
throw0101a wrote: post #360

Earlier quoted context omitted.

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

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

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

#424

Post by tinco »

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 shouldn't run an application like vim in Docker. Unless your server is running Vim as some sort of service, in which case it should only open files in a volume you bound to it.

Vim is exactly the kind of application you would run in a virtual machine.

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

#425

Post by rubyist5eva »

joshbaptiste wrote: post #390
rubyist5eva wrote: post #257

As someone who is relatively new to the Redhat ecosystem, what exactly is the purpose of SELinux? If you only run trusted applications why do you need it?

Trusted applications can be full of vulnerabilities that allow them to become malicious. SELinux and such can limit the capabilities of such trusted applications to do only what they were designed to do and not execute reverse shells or run Crypto mining software etc..

Makes sense, so it's basically an alternative to apparmor?

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

#426

Post by AndyNemmity »

mwmisner wrote: post #369
AndyNemmity wrote: post #350

Earlier quoted context omitted.

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

I totally agree that system design questions can be silly sometimes. When I do system design interview questions for senior engineers, I ask a really broad and complex questions and let the candidate drive us towards the system. The point of the interview is evaluating if the candidate can complete those soft skills in a reasonable way. I try to answer basic questions such as these: Did the candidate just go for desi…

That makes sense. I guess I've delivered incredibly complex systems in a tremendous number of diverse use cases, and yet I have zero confidence I could pass a systems design interview.

The few times I've had them, they've focused on how much knowledge of a particular choice I have.

When I build systems, it's incredibly common I don't know much about the topic. Especially in innovative spaces where you're literally the first team ever building a solution at this scale.

Take for example critical feedback, I can't imagine having to judge someone on that in an hour phone call.

The best teams argue quite a bit. That's healthy and reasonable. The question is if they accept, and respond to the argument, with positives and negatives, and how basically how they dance.

I don't know how to put into words what that dance is like, but you know it when you feel it. Maybe that's what you're looking for, a feeling of what that dance is like, but I'm glad I'm not making that determination on a quick basis.

Just random thoughts, thankfully I get all my employment through glowing referrals, and try to avoid interviewing anywhere without them so I can skip all of this questionable stuff.

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

#427

Post by Sebb767 »

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.

Ransomware incidents are rampant and PII breaches are quite common. Remember Equifax, who lost the PII of basically all adult US citizens?

Sure, there are extremely sophisticated, targeted hacks. But those are the minority. There are also hacks where hacker groups accidentally (!) shut down an oil pipeline. The reason the internet hasn't completely burned down is three-fold:

- We accepted breaches as something "that just happens" and that "nothing is 100% secure" - which is true, yes, but applied very broadly.

- Our operating systems are generally well secured and most exploits are very situational.

- The hacker groups (at least most of them) don't put in too much effort either, since they make a very good living of the lowest common denominator.

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

#428

Post by d2wa »

lakomen wrote: post #279

I've advocated for years that each program should be ran as its own user and group, isolated from the rest of the system. So let's say you run Firefox, is should run as firefox_username user and group. This way any exploit is ran with the user/group permissions, and unexploited it has no read write access outside its own user and group. Selinux is a beast but there are tools to help with determining which settings ne…

That works for services but not apps. For apps, Flatpak tries to solve this.

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

#429

Post by jlgaddis »

dale_glass wrote: post #180
kelnos wrote: post #173

Earlier quoted context omitted.

I get your overall point, but your example is not a good one: on Linux, at least, xscreensaver does not have a component that needs to be setuid root. xscreensaver-auth uses PAM to authenticate, which (typically) runs a small program called unix_chkpwd, which is setgid shadow ( not setuid root), as /etc/shadow is owned by root:shadow and is readable by group. xscreensaver is one of the very few screen lockers that is…

Oops. Yeah, serves me right for writing from memory, pretty sure it was setuid at some point in the past. > That sounds pretty overengineered. All you need is a small binary that is setgid shadow, that can take username/password on stdin, and exit 0 if auth succeeds, 1 if auth fails. But we already have that: unix_chkpwd. That's probably too limited actually. Because you can have a whole bunch of stuff in PAM: LDAP,…

> That's probably too limited actually. Because you can have a whole bunch of stuff in PAM: LDAP, OTP, Yubikeys, and all kinds of other fancy modules. Doesn't seem that unix_chkpwd handles any of that.

Yes, you're right. unix_chkpwd doesn't handle any of that and, in fact, was never intended to handle any of that -- and that's the entire point!

The entire design of PAM is, well, to have separate "modules" that are "pluggable" depending on how you need to handle "authentication" -- LDAP, OTP, Yubikeys, etc.

That is, the pam_unix module (which uses unix_chkpwd) is used when you enter in your (local user account's) password. If you're using something else -- LDAP or NIS or whatever -- for user accounts (i.e., your "passwd" database) there are separate (PAM) modules for that!

> Also, I still think it has to be a network service, ...

No, it really doesn't and, besides, there are other alternatives that would be much better to use instead of a network socket (such as a local UNIX socket, for one).

I really try not to make such remarks here on HN, but in this case it does seem that you have a fundamental misunderstanding of just how this stuff works (which is almost certainly why you're comment has been so downvoted).

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

#430

Post by greedo »

Spivak wrote: post #422
greedo wrote: post #414

Earlier quoted context omitted.

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

> And then the container's OS gets breached This can't happen. There is no "OS" actually running. It's a bunch of binaries and files sitting in a tar archive that the process running can access and link against. What are you going to breach? All the networking, firewalls, kernel, remote access like SSH, and privilege management is the hosts. The only process running in the container is the application. What you mean…

Thank you for this clear explanation without any attacks! I hate to think how many people I've misinformed about this at work. I think what caused my confusion is how our devops team has been using Docker. They've basically treated it as a vm environment that doesn't require approval from my team. And some of their practices just seem to cause me stress that I should just free myself from.

Would it blow your mind to hear that some devops people actually run more than one application in a container? And that one of those apps might just be sshd? That's one of the many that I know about. Why they wouldn't just run docker exec?

Post reply on HN