I’ve been using Fedora this time around since about FC33, having touched it a bit pre-20, and mostly used Slackware, Arch, Debian, Void and Nix in the interim. I like Silverblue in particular, but can’t really live with it on the desktop for more than a couple weeks. I use CoreOS for container deployments because rpm-ostree in that situation is a perfect fit. Also during that time, I worked a lot on Solaris, starting with 2.5.1, eventually working on a nevada cluster of a couple dozen sun machines running many solaris zones (aka containers). Solaris zones were the original work that went on to make LXC. Solaris also implemented security in such a way to satisfy US government requirements, which were a large part of Sun’s business back then.
Having declared my temperament and hopefully evidenced my familiarity with the problem of information security, I must now tell you that I’m struggling with the pointfulness of SELinux on the desktop. Does anyone have any examples where SELinux improved their quality of life on a desktop? Or even an example of something being revealed that needed to be fixed (and I don’t mean “fixed” as in silenced, I mean triggering some action on the user’s part which makes their lives safer or better).
If you aren’t implementing labeling, or compartmentalization, or even some kind of RBAC which has a context larger than the individual desktop, why is this a good thing?
Given that all I have ever done with the notifications is silence them, because they NEVER have represented anything nefarious, is there any benefit at all to me keeping SELinux switched on?
“But think of the securities” is not a good answer - anything which requires workarounds and socializes ignoring security warnings as normal is an anti-security feature. Pretty soon you’re treating them like the “whatever” button you click when a certificate doesn’t validate. When was the last time a browser warning about a site you needed to go to had an impact on your behavior? If you really wanted to click? (Other than feeling a twinge of irritation I mean, which seems to be our expectation when dealing with technology these days, another norm I reject.)
Anyway, this is very obviously a non-urgent and very loaded question. I’m not intending to pick any fights, I would just like someone to convince me that SELinux on the desktop outside a classified information environment isn’t performative nonsense.
SELinux is useful when properly configured. It helps reduce the attack surface by restricting an app to access what it needs only. For example the SMB daemon can’t access anything not labeled for SMB sharing. So if your SMB server is compromised it won’t affect the whole system.
Another example is a post I read somewhere about a bug in steam that can wipe a user’s home. A user reported that nothing happened to him because he restricted steam to it’s own folder only, so it was blocked by SELinux from destroying his home directory.
SELinux can do more than that but that’s what comes to my mind.
Don’t think of SELinux as something that scans your system looking for potential issues. Instead look at it as more of a zero-trust thing, reducing the attack surface by letting applications only use the specific resources that they need. Or think of user permissions: on a multi user system you could just let everyone run as the superuser all the time – what’s the risk, these are all users we trust, right? But either a typing error or malicious intent means the entire system could be wrecked, when there are no restrictions. So instead we restrict users under normal conditions to being able to access those files for which they have rights. SELinux is of that nature, restricting apps.
It isn’t that I don’t know what it is, or what it does, or essentially how it works. I can even think of hypotheticals like the SMB one and the (rather silly) steam one. I also get that there is a large community of people who share the view expressed in https://stopdisablingselinux.com/ that everyone owes it to themselves and the world to devote a few days of their labor to learn the tool before attempting to, I dunno, stop thinking about pointless stuff that pays literally no bills (except maybe the professional services industry).
As with so many attempts at security SElinux just relocates and obfuscates the problem, making it more complex and difficult to reason about (as, say, a writer, or a musician, or an accountant) and therefore demanding far more trust than more straightforward systems. (Recalling that trust is not verification, it is what is required in the absence of verification)
I honestly think that getting indignant because people turn it off is to side-step the point and indeed, continued relevance.
But I clearly am in a minority in that I wouldn’t trust a computer connected to a network with anything truly important (y’know - life threatening things, not commerce which is basically trivial). I wonder what it is that motivates the efforts to socialize SELinux with that kind of populist judginess about disabling it, and what objective that serves.
There is setroubleshooter, which notifies you of selinux alerts and suggests solutions in case the behavior is intended.
Also the average person may get away with default configuration. If all what you do is browse the web, consume multimedia and edit office documents SELinux is very unlikely to get in the way while improving your security at the same time.
Even if you don’t have much valuable information, it is better to have proper security measures in place.
I mean, sure, I agree with the statement that “it is better to have proper security measures in place”, but that doesn’t address the “properness” or “securityness” of SELinux.
As for “the average person”, maybe a person who doesn’t install any software or make any changes to anything once installed. I get warnings when I install fonts, or when I do something like modify a Dropbox file, or some random thing.
Everyone is trying to make me see that security is good, but no-one is telling me how SELinux is security.
Here is, perhaps, a more crystallizing question: Is there any point in SELinux on the desktop if you enable passwordless sudo?
If so, how does it help prevent non-accidental breaches?
If not, are we not saying that SELinux’s usefulness vanishes as soon as you put sudo behind a command? Or when you run something which uses sudo to escalate privs without you noticing?
My point is that in the absence of a well defined threat model, inconvenience is more likely to screw you than some default security posture you don’t understand, and which you will make a tiny change so you can move along. Security is good, yes, but only in context. Maximalist security postures (or even just terrifying incomprehensible messages) are not effective, particularly if the goal is not even stated.
You can’t do things on computers without also being able to do bad things on computers. Or having bad things be doable. Moving the lines around and then yelling at people who don’t care enough to buy a new map every weekend isn’t going protect people from their root password. In fact the more pain you make, the less attached to their root password they become.
I marked a solution, not because it’s a solution, but because it seems like the most useful thing to come out of this. Since I’m talking across everyone else, I will call it a day. Thanks for the feedback everyone.
SELinux can confine root processes, using sudo you can run selinux config commanfs, but a root process that doesn’t have the right context can’t.
It is the principle of the least privilege, each process is restricted to what it needs only. Http server restricted to its files and config only, SMB to its shared folders, SQL to whatever database/configs it has. So lets say your http server was compromised and has root privileges, it will be blocked by selinux from accessing anything not related to http.
But what is the reified policy which represents the “principle of least privilege” on a general purpose development desktop?
[Edited to add: also the examples you give are all services which aren’t much relevant to my dev desktop, which is the context of my question - note “general purpose” “dev” “desktop”, these are all key to the point I’m making. Principle of least privilege implemented for infrastructure should be implemented as you say, but per instance - it can take quite a long time, using human judgement, to tune and harden a system to a useful level for infra, but you wouldn’t then fire up a firefox on there. For my dev desktop, well, setting aside SMB which is outside my experience, none of those things will ever happen outside of an OCI container.]
Because it seems to me that unless you know the threat model more specifically, the answer to that question is “a process should be allowed to do all the things it does”. Otherwise, it is a broken process. If you know the threat model, then you can usefully intervene. If you do not, you are guessing.
It’s like a strongly typed generic function. If you have a function f which takes a value of type T and returns a value of type T, unless you reify T, then the function can literally only return the value it received. There is no other operation that can be performed because you don’t know anything else about T.
What I am saying is that without that additional context, there can be no meaningful policy which does not either a) allow any action desired by the operator or b) fail to be a useful tool.
But when we do security with computers, instead of attempting conceptual clarity, we smear complexity over every available surface. It is incoherent.
The context is the allowed operations of the running process.
In the example given above, regardless of the user rights (including root) if the http process is only allowed to access files and actions within the http realm then it cannot, even if compromised, manipulate data or files outside that realm.
Similarly a user cannot create or execute a malicious program that attempts to manipulate data that is outside the context allowed for that user. They can however manipulate anything that is within the context realm they are allowed.
SELinux defines the context that each process is assigned and ensures that users and processes are limited to an acceptable realm of permissions. This is finer grained than is available with the pure unix style UGO permissions and functions with processes and not purely with the user attempting to access something.
It is up to the system admin whether to use selinux or not, but the tool is as loose or as restrictive as desired.
So actually, for my use-case, the correct solution is to disable SELinux?
Correct me if I’m mistaken, but it reads like you’re saying that if we know in advance what a process is supposed to be allowed to do, we can implement fine grained controls to ensure that only those actions are available to that process. But if we do not know what it should not be doing, or if we do not know in total what it should be doing, then the correct solution is to not use SELinux.
That sounds like a good answer! It was my starting point.
Not exactly.
The provided selinux policies do that for you already. If you find that your use case is outside the normal boundaries then yes, you can choose to either disable selinux (switch to permissive mode, which will still give you an alert when things are outside the policy boundary) and/or make selective changes to fit your needs (usually based on those alerts).
So, RTFM because if you can’t get your computer to work it’s down to your lack of expertise and less complete understanding of kernel based execution controls.
Or copy/paste the suggestion from the alert?
As I said before, this makes a lot of sense in many production and infrastructure contexts. I think the notion that people who are generally technologically literate, or who are even programmers who just don’t have a lot of experience implementing security of any kind, will be able to intuit their way through fixing SELinux, or even will want to invest their labor as demanded by stopdisablingselinux.com, is misguided.
Back in the day, I worked a lot on Solaris and in network security at Sun. I even helped write questions for the Solaris 10 security admin certification, and OMG is it ever not easy to understand the second order consequences of even RBAC constraints. It takes a lot of time and work to make a computer do anything useful while being adequately minimized. There is no “principle of least privilege” standing separate from the context, it is a phrase used to suggest an approach, a posture, not an implementation. Least privilege implemented on a system which has no specific task to perform is simply to switch it off.
In the default configuration, the login user runs unconfined, that is, there are no SELinux restrinction on user processes, and with sudo the user can do anything including destroying the system.
Also the web browser runs unrestricted, so the security of the browser depends on the browser itself to properly sandbox the javascript programs.