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

231–240 of 461 posts

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

#231

Post by perryizgr8 »

Hikikomori wrote: post #129
perryizgr8 wrote: post #118

Earlier quoted context omitted.

> Because plenty of unscrupulous ISPs and governments log unencrypted web traffic. Ok. Not relevant here. I don't care if my ISP knows I'm learning SELinux. And they would know that even with HTTPS. > Some ISPs use that information for advertising, or inject custom javascript into unencrypted web pages Sounds like an ISP problem. Buy service from a better one. No need to impose SSL on the website for this. > HTTPS is…

>Sounds like an ISP problem. Buy service from a better one. No need to impose SSL on the website for this. Just move I guess.

Or don't. It's not a problem that needs to be solved server-side.

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

#232

Post by consp »

throw0101a wrote: post #229
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…

> 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. If it's not secure don't sell it as secure: see the difference between Linux containers and FreeBSD jails or Solaris zones. > You can't even blame the applications for that. Let's say you want to…

> it is your responsibility to know how the components you choose work and how much you can rely on them

Unfortunately that is not always your choice and arguing against it most commonly costs you more than you like. My experience is quite often timelines get underestimated massively with software so you end up doing what you can with the resources given. If you pull this into the bridge metafore the bridge still stands but can collapse any time and as long as it doesn't collapse during rush hour and can be rebuilt before the next morning it's all fine.

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

#233

Post by throw0101a »

nisa wrote: post #177
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…

> Wouldn't it be great if the man page of getaddrinfo mentioned those (mine only mentions gai.conf) That's a huge part of the problem. Was looking for a monograph to pass on my successor that wasn't so familiar with linux - modern linux - as in systemd, docker, nssswitch, pam_homed, network-manager is penetrable but more often than not I'm just looking at the c source in github and I am in my 30ies, starting in my te…

> there is no overview documentation,

Documentation on Linux has always been shit.

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

#234

Post by mmis1000 »

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…

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 problematic, because dir mount will be almost alwyas read-only now.

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

#235

Post by tinco »

ximm wrote: post #25
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…

I agree that containers are easier to manage than SELinux, but still not easy enough. Linux provides many low level primitives for restricting applications and SELinux, Apparmor, Docker, Flatpak, and systemd all provide high level abstractions for those. But IMHO none of them really finds a sweet spot between flexibility and usability. `systemd-analyze security` for example lists 80 (!) different settings, even thoug…

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 port that an application can talk to, that's safely isolated in a docker container.

Maybe that's just daydreaming about a perfect world, but I agree that it should be easy to reason about the access levels.

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

#236

Post by user3939382 »

ptidhomme wrote: post #153
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…

Let's say you want to build a good, secure application. How do you know what files your application will try to open? What syscalls it wants to call? This almost looks like a hint to OpenBSD's pledge and unveil system calls. I'm just a hobbyist, but regarding we all run software we don't understand what I like (again) in OpenBSD is that I feel I can largely understand/control what's happening in my system, it quite f…

Exactly. ‘ps ax’ on a fresh OpenBSD install gives you about 10-12 processes, each of whose purpose is either obvious or easy to discover.

Try doing the same thing on macOS or Ubuntu. Last time I looked carefully at the former I discovered, for example, daemons for classrooms (??) It’s a free-for-all.

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

#237

Post by kllrnohj »

Hnus wrote: post #164
dijit wrote: post #144

Earlier quoted context omitted.

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…

WASM will probably be always slower than native but call it very inefficient is unjustified imho considering the compiler needs to be fast enough to run in browser from what I have seen its around ~1.5x slower than native code with there still being many low hanging fruits to be optimized.

1.5x slower for a weak sandbox that's already hardware compromised (spectre) with no plans to ever be fixed, along with a questionable portability story (cool the instructions itself are portable, but there's no APIs. Which are, and always have been, the actual portability issue) does not exactly sound compelling. It makes sense on the web where the browser is already providing API portability & permission sandboxing, and all that's necessary is actually just instruction portability and protection against eg memory corruption (actual security sandboxing still being done via process isolation), but beyond that? Like desktop apps? Pretty much entirely useless.

And it doesn't address any of the issues here anyway. As soon as you bind libc to it (or any other system library), which isn't exactly unlikely, you're right back into the problem of not knowing what the selinux policy should be. And you still want selinux policies since WASM is only a memory sandbox, not a permission sandbox.

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

#238

Post by kllrnohj »

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…

Ideally all apps & libraries would ship their own selinux policies with a common framework for combining them & base layer for privilege sets (eg, "let me open any file the current user can open" or whatever). If that was the case then your concern wouldn't be an issue. You'd just say "I use libc sockets" and you'd inherit whatever file path permissions are necessary for that to work, as defined & exported by the libc in question.

But that's not a thing. So distros are attempting to add it later themselves, which is a disaster.

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

#239

Post by dale_glass »

Edynamic77 wrote: post #218
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…

SELinux is so ridiculous. If you want a real security on linux where root is not God ! Go to this site. https://www.rsbac.org/ It's little difficult to implement (by kernel customisation) but there is a learning mode to secure all Linux structure Be "root" is not be "God" after implementation. You will must ask to Security Officer (SecOff) You can speak of "Evaluation Assurance Level" with this security solution and…

root is not God under SELinux either. root processes are also confined.

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

#240

Post by brightball »

consp wrote: post #232
throw0101a wrote: post #229

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. If it's not secure don't sell it as secure: see the difference between Linux containers and FreeBSD jails or Solaris zones. > You can't even blame the applications for that. Let's say you want to…

> it is your responsibility to know how the components you choose work and how much you can rely on them Unfortunately that is not always your choice and arguing against it most commonly costs you more than you like. My experience is quite often timelines get underestimated massively with software so you end up doing what you can with the resources given. If you pull this into the bridge metafore the bridge still sta…

Yep, this is accurate. People making decisions often value “works”/“ships” more than “secure” and the time allocations reflect it.

I wish it wasn’t the case, but it is.

Post reply on HN