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…
SELinux is unmanageable; just turn it off if it gets in your way
111–120 of 461 posts
Re: SELinux is unmanageable; just turn it off if it gets in your way
#112I 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.
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
#113The 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 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
#114Earlier 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?
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
#115Earlier 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.
Re: SELinux is unmanageable; just turn it off if it gets in your way
#116Please 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.
Re: SELinux is unmanageable; just turn it off if it gets in your way
#118Earlier 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…
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.
Re: SELinux is unmanageable; just turn it off if it gets in your way
#120The 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…
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.