SELinux Misfeature (Again)
Just a note on yet another design misfeature in SELinux I've found. I've talked about the numerous problems that make SELinux not only impractical, but insecure by nature, before. This one has only recently occured to me, after seeing some bugs caused by (wait for it) ... SELinux misconfigurations.
This note is on how SELinux "enhances" security of the machine. The way SELinux works is by restricting rights. You take a program that is running and remove some of its powers, thereby ensuring it can only do what you want it to. When done properly, you'd remove all the process's rights and add back only those you specifically need. Of course, doing this in SELinux is a huge pain that even the experienced SELinux developers have trouble getting right for a huge number of common applications, but that's not today's warning.
No, the problem is that SELinux works by removing rights. Say you have a program which needs to have certain privileges that normal applications run by normal users don't have. Since SELinux can't grant privileges, only revoke them, you must first give the program elevated privileges. For example, making it setuid root. Then you use SELinux to remove those root privileges you don't need, giving you what you do need.
Aside from the problem noted above in how hard it might be to make sure you revoke everything necessary, there is still the problem where the file system gets out of sync with the intended SELinux access controls (you lose the SELinux tags on the file, for example) or in which the machine may be booted temporarly with SELinux disabled. What's the problem? You've got commands that users can execute which have root (or similar) privileges. Setuid root programs, for example. While there are certainly perfectly secure machines with setuid root apps around without SELinux, a machine that was designed with SELinux in mind may find that it can't securely cope with a lack of SELinux, or with SELinux functioning less than perfectly. SELinux is like an electronic lock that unlocks when the power goes out - when the power is out, attackers have free reign of the system.
A better electronic lock would instead stay locked when the power goes out, and simply lose the ability to unlock. In this case, SELinux wouldn't take an insecure machine and secure it; it would take a too-secure machine and open it up enough to function with all requested features.
At first it might seem a bit silly. After all, you need the machine to be usable with SELinux off to do whatever maintenance is necessary, right? The answer, of course, is that the machine *will* still be accessible. You might have to boot into single user mode, but it'd still be quite possible. With SELinux malfunctioning, the machine might stop being able to do certain tasks, but security is not compromised. The web server might not be able to serve pages to customers anymore, but attackers also won't be able to crack the customer credit card databae, either. You guarantee that at no time, ever, with or without SELinux, will the machine ever be inherently insecure. When SELinux is on, everything works as intended; when it's off, the machine is secured tighter than ever.
Such a machine would, for example, have no setuid root executable, or even any processes running as root. Not one. The entire system would be running as non-privilege users. For those apps that need classically root-only privileges, such as a network daemon opening a port below 1024, or the login program, they would still not ever at any point in time run as root; SELinux would just grant those processes the ability to access the resources they need (such as the passwd files for login).
This sort of secured system might work by even removing from the kernel any uid==0 checks. In no case will there ever be the ability for a process to run with privileges not explicitly granted to it. The only exception would be something like single-user mode, which can only be entered at boot up, of course.