Live data from Hacker News

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

ctrl.blog

111–120 of 461 posts

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

#111
post #34

How can I trust some opaque policy I cannot see? Not just trust that it is well intentioned not evil, (Oracle Linux?), but that it does what it says. And does what I need and that the opaque developers have correctly envisioned what I need to do. Security by obscurity is worse than none at all. Security by buying an "Enterprise" product is worse than that. What SELinux says is " real MAC security is super complicated…

> but you can't understand it or change anything" That is not true. SELinux is not hard to understand nor change. Most of the issues you might encounter are simply solved by changing a label in a file or directory. It is just not straightforward to debug and understand if you don't know it is there. I think most people who complain about it are multi distros/OS users and just only realize after losing precious time t…

But what am I, as the sysadmin, supposed to label things? Even if I know that I probably need to apply some labels, how do I find out what the policies are? What labels can interact with this program? You can turn to Google and find some incantations in a blog or forum post from ten years ago, but you can‘t easily see which labels a program is allowed to interact with or not. (If you even know to ask that question.)

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

#112
post #38

I have to say, for sysadmin work I find this view sorta overblown. My experience is with RHEL and derivatives, not Fedora, and for the most part those are very straightforward and while selling does rear it's head every once in a while, it's usually not that problematic to work around. When you have something failing that you need to fix and isn't an upstream problem (i.e. your own app or some third party vendor), yo…

The three paragraphs starting with "In the best-case scenario" address exactly what you're talking about. And in my brief (hobbyist) usage of CentOS 7 with trying to run some self-written software, what TFA says was exactly my experience. As it turned out, the hardening provided by systemd (private tmp, restricted syscalls, etc) was sufficient, and easier to understand, for my use case.

Sure, but it also sounds like your usage isn't really sysadmin level, which is what I prefaced everything I said with to put it into that context.

I don't expect random users to run with selinux on and deal with problems for all the stuff they might do. I do think it's probably a good idea for system administrators, and if those sysadmins have problems getting some custom in-house software running through selinux, that seems like a good place for them to focus some learning to rectify that issue.

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

#113

The advice is poor and shows the authors lack of basic ability to understand basic selinux tooling. It's doubly bad because most people running modern Linux run their apps in containers and don't need to understand it as they don't run into problems. I'd this really is what gets the pageviews maybe someone should write a how-to on disabling all permissions because it's too hard.

Should I agree with the hivemind like this ? Oh, What I meant to say is. The author is correct, selinux is too hard. I too am incompetent and unable to understand the many examples that demonstrate solving selinux issues. What we really need is a shittier solution that lets good programs work while stopping bad people from doing bad things by using psychic powers and having a deep understanding of software that is ye…

Author is correct that SELinux is not trivial and takes work to figure out.

Author is full of it in that they're obviously not aware of the tooling and information available. Eg:

All of this is wrong:

> Fedora Linux. There’s nowhere on the system where you can view the policies and look up why something might or might not work.

You can install the policy's source and look at it all you want. There are also tools to examine the current policy.

> The SELinux denial audit log messages are too vague. You’re told that a label was denied reading from another label. Okay, what do those labels mean? Which programs? Which files, sockets, or whatever?

You get that in the logs. What you get is an inode number, which isn't very user friendly, but it's very much there. SELinux has tooling to turn the log messages into something nicer to work with.

> So, you run the audit2allow command as instructed, and end up with some policy blob files.

> God only knows what changes the blobs do; you can’t be expected to, nor are you given enough information to evaluate them.

This is also wrong, along with the blob you get a text file.

TL;DR: The author has a minimal point, but clearly hasn't read the docs. Help and tooling is available and not that obscure.

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

#114
post #11

Earlier quoted context omitted.

There's something funny about a website about teaching security practices being unavailable through HTTPS. It looks like the website is hosted by github pages, and the author didn't bother setting up SSL correctly.

Why would you need SSL/HTTPS for a casual game like this?

Because plenty of unscrupulous ISPs and governments log unencrypted web traffic. Some ISPs use that information for advertising, or inject custom javascript into unencrypted web pages their customers visit for who knows what reason.

HTTPS is free and stops most of these tricks from working. You can still sniff the domain name via DNS or SNI, but HTTPS blocks attackers from seeing the URL you're visiting, or seeing the traffic the server sends back. It also stops people from doing MITM attacks on the connection.

Its 2022. HTTPS is fast, it works great and its free. Use it everywhere.

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

#115

Earlier quoted context omitted.

Why would you need SSL/HTTPS for a casual game like this?

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.

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

#116
KubeArmor (https://github.com/kubearmor) makes implementing SELinux policies easy for your host / k8s workloads.

Please do checkout the project and provide your valuable feedback.

All of our policies for SElinux are Auto generated using https://github.com/accuknox/discovery-engine

Writing policies by hand is nearly impossible, error prone and that is the exact problem we are trying to solve - to make SELinux and AppArmor easy for K8s workloads and now host based workloads.

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

#117

> Red Hat Enterprise Linux (RHEL) has some of the most accessible documentation on creating custom policies. Red Hat is the Pinterest of Google searches for Linux problems. You’ll often find a page where someone is describing you problem but the resolution is locked behind a subscription login.

You can get to some of the resolutions (but not all) with a free RH developer account.

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

#118

Earlier quoted context omitted.

Why would you need SSL/HTTPS for a casual game like this?

Because plenty of unscrupulous ISPs and governments log unencrypted web traffic. Some ISPs use that information for advertising, or inject custom javascript into unencrypted web pages their customers visit for who knows what reason. HTTPS is free and stops most of these tricks from working. You can still sniff the domain name via DNS or SNI, but HTTPS blocks attackers from seeing the URL you're visiting, or seeing th…

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

Absolutely not. It takes time and effort to set up. And then maintain forever. Plus you're introducing an unnecessary dependency on multiple third parties.

> HTTPS is fast

HTTP is faster.

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

#119

> Red Hat Enterprise Linux (RHEL) has some of the most accessible documentation on creating custom policies. Red Hat is the Pinterest of Google searches for Linux problems. You’ll often find a page where someone is describing you problem but the resolution is locked behind a subscription login.

Amen.

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

#120

The gist of the problems is that the policies are not transparent (probably due to security reasons?) to the user/admin, did I get that right? And that there's a difference in enforcement between user policies and policies provided by the distribution? All this sounds to me like a good idea that got lost in the implementation. If you have no way to look up which policies are in effect and what is labeled and how, som…

They make it so that you usually don't have too. You run into selinux issues usually only when you: - run some server stuff - try to serve a non default directory

And 99.99% of the time you will usually understand the issue from the log file and just label the correct files/directories. All this without having to change a policy. Policy creation/modification is pretty much the job of a package maintainer only.

I have been using Fedora daily for something like 7 years and have never had to write/modify a policy. The article originally linked is about some guy who do tests and run beta distros on prod and fiddle with his system by blindly copy/pasting stuff he sees in forums without really trying to understand what he does, then complain about his distro breaking on update. I don't think you can ever render your distro unbootable unless you do some very stupid things. And Fedora do not steer you to do those stupid things.

There are just so many policies it is not practical to list them all if you don't need them.

Only complain I would say is that sealert is not installed by default so if you want to have desktop notifications about an selinux issue you need to install it manually. I'd prefer it to be just a toggle in settings defaulting to no to decide to show or not show those notifications.

Post reply on HN