Live data from Hacker News

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

ctrl.blog

251–260 of 461 posts

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

#251

This is not a good advice. You'll basically get Ubuntu that didn't have SELinux in the first place, and most people don't care. SELinux is difficult to build from scratch but there are decent tools to build your policy in an automated fashion. The advice should be this: Don't have time to deal with SELinux at the moment? Switch to permissive policy and deal with it later. I included SELinux as one big chapter in my b…

That's not really great advice either, temporary solutions/workarounds have a tendency of sticking around permanently.

I say this, because it's very hard to write the policy yourself at the beginning. So let the system run for a week and then use the tools to build the policy for you.

I wish it's easier to sit down and write it, but it's not atm.

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

#252

Earlier quoted context omitted.

The engineer building the bridge is liable. Hence, you get engineers with qualifications (instead of a random person with X years in Y), and those qualifications certify they know what they are doing.

which is why bridges and buildings certified by qualified engineers have never collapsed

Both types of structures have collapsed.

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

#253
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 Reminder: containers are not meant to be security tools. Fine-grained sandboxing (e.g. seccomp) is. And it can be layered upon OS-level VMs. Additionally, bundling tons of stuff together with an application (like docker but also flatpak do) is not good for security. Same for static linking. They all increase the workload of…

How does static linking increase workload?

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

#254
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 problem is not so much that selinux is too complicated (it is as complicated as it needs to be)..."

Completely disagree, if the target users are advising each other to disable it... then the tool is definitely more complicated than it needs to be.

Using tools that don't hide any complexity are very painful to use. It feels like the creator doesn't care about the user and put no thought into the display of information or workflows of the tool.

Solving a complex problem with a perceived complex tool is relatively easy... don't hide any complexity.

Solving a complex problem with a perceived simple tool is difficult... hiding complexity at the right time, revealing functionality it based on the user's intentions and experience is not easy but greatly appreciated.

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

#255
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 problem is not so much that selinux is too complicated (it is as complicated as it needs to be)

I disagree.

> but that we all run software we don't understand.

I fully agree.

My disagreement lies in the fact that you've described the problem, but are proposing that some software (SELinux) that fails to solve the problem is somehow good.

SELinux might be a perfect tool in an ideal utopia where everyone understands all the software they run, but that isn't the real world, and having a tool that works in a theoretical world isn't particularly useful.

Either SELinux is applicable to the real world, or it's not useful and not really fit for purpose.

This isn't a "blame game" - it's not about figuring out why things are bad (no-one understands their software components), nor blaming SELinux (it hasn't caused these problems, it's just failing to mitigate them). It's about figuring out how to improve that situation. Does SELinux do that effectively?

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

#256
90% of the places I've worked, it's either been turned off or blindly hammered with audit2allow until SELinux shuts up.

Mostly because the "admins" are too lazy to do things the right way (non-standard file paths, ports, etc) or create/change the actual required context/labels. I'll admit that like anything it can be cumbersome at first and frustrating to learn, but it is helpful.

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

#258
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…

Some of the problem is that historically we've built systems badly engineered for security. Take for instance something like xscreensaver. Something in there needs to be setuid so that it can verify your password to unlock the screen. That something is fortunately a dedicated binary, and not every single screensaver, but still, that's bad. Writing that executable is a delicate thing. Get one of them wrong, and it's a…

Well I have been playing around with Wayland + Sway the last month. I like it but there are some caveats. For example I end up modularly picking the tools I want to use with it. So by default I think there is swaylock and then there is waylock but a few times I got back to my seat and the locking application had crashed, exposing my session to my co-workers. That ain't the desired effect. I resorted to physlock which swaps to tty and allows to disable things like echoing of kernel messages and sysrq. It has yet to crash. Also, all of this relies on PAM and according to the OpenBSD devs PAM is a mess.

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

#259
post #247

Earlier quoted context omitted.

The engineer building the bridge is liable. Hence, you get engineers with qualifications (instead of a random person with X years in Y), and those qualifications certify they know what they are doing.

Which in my opinion brings up the certification argument, but I, as I’m sure others, have found that most certifications mean nothing in regards to whether someone can actually do the job. Is the key component missing in hiring in our industry a vastly more rigorous/extensive/difficult testing and certification protocol?

Yes, and in other engineering disciplines this level of rigor does exist. https://en.wikipedia.org/wiki/Engineer_in_Training

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

#260

Earlier quoted context omitted.

I've been recently thinking along similar lines about libraries. In web dev, it's common practice when you have a problem to first look for a library that solves it for you. I get the "don't reinvent the wheel" sentiment but, I think we take it too far sometimes. I've been looking at the source code for some dependencies at work lately, and many of them actually don't hold up to our own code quality standards. Kind o…

when it comes to JS libraries I'm usually a lot more interested in how good their testing is. Code quality can be very subjective in some areas. But if the dang library doesn't have a lot of good testing then I can't really trust any updates from it :/

Inadvertant bugs are the last thing I worry about in the javascript (node) ecosystem.

I'm more concerned with the fact that running anything requires transitive trust to hundreds or thousands of projects in node_modules, any of which can run scripts while being installed.

How many people out of a thousand would you trust running commands at your terminal?

Post reply on HN