81–90 of 461 posts
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?
How does SElinux compare to Secure Boot / SIP?
You can use SELinux without Secure Boot and Secure Boot without SELinux. Secure Boot can make SELinux more effective, because you can use it to verify that the kernel is not tampered with, so you know that it is properly enforcing the SELinux policies. You could also verify cryptographically whether a policy is not tampered with, but I am not sure if that is currently supported.
The comparison between SELinux and SIP is a bit more complicated. SELinux is a security framework that allows you to write all kinds of policies, whereas SIP is a very specific set of defenses.
On of the main features of SIP is that it makes certain system paths unwritable for every process that doesn't have the right entitlements, including processes with PID 0 (root), unless they have the the necessary entitlements [1]. Since SELinux is a generic security framework, you can implement something similar to SIP's path protection using SELinux. For example, system paths could be labeled with a special label and writes can be restricted to processes with a particular SELinux context. More concretely, you could use SELinux to forbid that any process, including root processes, can write to a system path like /usr/bin. Then you could allow the security context in which DNF/RPM (the Fedora package manager) run to modify system paths like /usr/bin [2].
[1] SIP does more stuff, like disallowing unsigned kernel extensions, preventing code injection, etc.
[2] Russell Coker has set up an SSH machine for which he gives away the root password. But you can't do much with it, because the SELinux policy prevents you: https://www.coker.com.au/selinux/play.html
> 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?
Improve logging in the SELinux system. Clearly it was able to map the program/files to labels, why aren't those programs/files provided in the error message?
> There’s nowhere on the system where you can view the policies and look up why something might or might not work.
Improve SELinux's policy analysis tools. As it is, it appears `seinfo` and `sesearch` provide too much detail and are impossible for non-experts to use. Are there alternatives that any sysadmin can use?
> A package’s SELinux policy is — most often — not part of the package but is installed as part of a larger meta package containing tens of thousands of policies (e.g., the Fedora Linux project’s selinux-policy mega-package).
Policy should be included with the software package (or have a clear, computer-resolvable link to the package the policy applies to).
Seems to me that SELinux is an afterthought in most distributions, which I can understand in volunteer/community-driven distributions, less in Enterprise ones. How does RHEL do it?
--
However, the fact that these problems remain decades after the introduction of SELinux (2000!), indicate a lack of will by the Enterprise Linux/Security industry. Considering its origins at NSA, which I'm sure is willing to train its sysadmins and not bothered by its obtuseness, I'm not surprised.
Luckily, I think there’s a lot of community work coming up to make these policies easier to write and more robust.
For example: https://github.com/dburgener/cascade Is a DSL for writing SELinux policy, and seems to aim to provide a better audit tool.
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…
Does anyone have any examples of where SELinux saved the day? I appreciate that some of the time you'd never know, but I am curious if anyone has any real life examples where it stopped an attacker.
Not so much an attacker but bad actor(s)...
It has saved us from having people with expected (limited) access to systems from spawning services listening on the network that shouldn't be there
Granted, we have a default drop policy in the firewall, so it shouldn't really matter in a sense. I like the approach of not having the process rather than preventing access to it
The attacks could be worse. For example, some users SSH access was compromised and the attacker wants to use it -- opening a reverse tunnel on localhost out of the environment over their SSH connection... bypassing the usual perimeter for egress.
SELinux should provide some nice control over this that would be independent of service
But that said, it's not user friendly either. It's definitely a skill I list on my CV. Either learn it and feel better about it, or set it to permissive mode and live with that.
I agree with mindwok, SElinux defaults from distro + containers work just fine. Rarely any policy issues, and you get the isolation of containers on top of that. So I wouldn't set SElinux into permissive mode just to use containers, I'd use both. Which I currently am doing on my container host at home for example.
Edit: Today's press[1] have an excellent example of a vulnerability that should be stopped by SElinux default policies. Look at NetworkManager/dispatcher.d as an example, semange fcontext -l | grep 'NetworkManager/dispatcher' and you'll see it only has the exec context on that one directory.
So even if you could exploit a directory traversal and place malicious scripts in other places, it would not be allowed to execute them.
1. https://arstechnica.com/information-technology/2022/04/micro...
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.
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 yet to be written.
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…
Bubblewrap? FlatPak's sandboxing features are built on it already.
I see a few obvious areas of improvement, all of which are "implementation details" and don't undermine the core principles of SELinux. > 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? Improve logging in the SELinux system. Clearly it was able to map the program/fil…
This leads to everlasting APIs that can never get obsoleted, and on which "New and Improved" API replacements accrete, and then users get confused about which ones to use, and support effort gets divided.
I suppose such is the burden of choice.