ZWOS 4: MAC/RBAC basics in GNU/Linux:
So after the holiday break, we return this week with the promised basic explanation of MAC/RBAC systems.
MAC stands for “Mandatory Access Control”, and RBAC stands for “Role-Based Access Control”.
A few years ago, there was a strict divide between MAC systems and RBAC systems, but that is not the case any more, in fact, in the foreseeable future, all of this functionality will probably be integrated and expanded in systemd. Fedora is working hard on using new kernel features and systemd to integrate existing MAC/RBAC functions, and to add supplementary security functionality, bith on the access control side and on the reporting/logging side, but for the moment, this is all still in a pretty early phase, and in general, it would be an overstatement to say that systemd is adopted across the board in open source software development… after all, there is a reason why even Debian was actually forked rather successfully recently by a part of the Debian community that resisted implementing systemd, and chose to further develop the Debian base with SysVInit instead. This fork is pretty interesting, and is called Devuan (devuan.org), and even provides an upgrade path from Debian directly. The reason why this is interesting for some users is not because systemd is per se bad, but is because sysvinit is much lighter and more modular than systemd, it is easier to grasp and modulate a sysvinit based system than a systemd based system, so users that require super lightweight dedicated distro spins, will find a great help in Devuan in comparison to Debian… however, it’s also possible to go on UbuntuStudio for instance and brew your own cocktail without systemd, also thanks to the continued development on sysvinit from communities like Devuan. The reason why RedHat is pushing Fedora into the development of a systemd based integrated access control system is of course because they want to further take market share in the server realm from Debian, but that doesn’t change anything for non-commercial or self-managing users, it is of no consequence to the open source development and the availability of software as such.
Back to MAC/RBAC systems:
Most new users compare a MAC in Linux with the UAC in Windows. That is completely false. There is no common ground whatsoever between a MAC in *nix systems and Microsoft’s UAC.
The two systems serve a completely different purpose in that they start from a completely different logic: whereas a MAC in *nix systems is a genuine access control system, that requires actual authentication as a privileged user to perform certain tasks or give certain commands or set certain parameters in the system, Windows’ UAC is nothing but window dressing, it is not an access control system as such, because processes will be run as root according to the policies set for the system by Microsoft and by third parties and by system admins, the pop-up dialogue with the question whether or not a certain command or exe can change the system, is not a gate, it is but a reminder with a cancel option: the “root privileges” will be called by the system and the attributes of the executable code, and NOT by the user.
In *nix systems, a MAC is a real gate, that will not allow even a call for privileges if such call is not made by the privileged user, because only that user can set the attributes to allow for such a call to be made. A modern MAC/RBAC system will be provided with updated profiles in which the developers have defined the objectives of the software, and according to those objectives and common logic, code will only be allowed to access data or system calls (all the way up to the kernel that contains the safety mechanisms to enforce this) part of that user’s “space” and only those system resources required for that particular code to work. Everything else will be denied. That means that even when a linux user is running as root on his system, it is quite possible that his MAC/RBAC will block access of a certain program or process to a certain system resource, if that access doesn’t make sense for that program, either based on the user and his privileges, or the role of that program in the system.
There are two kinds of systems: those that learn from usage, and those that have an intricate system of internal system reporting that allows for a fixed but very complex and interactive access control. Examples of the former kind are AppArmor and Tomoyo2, whereas the ultimate example of the second kind in SELinux.
These systems provide a crucial extra safety net in *nix systems, as they are capable of limiting or excluding exposure to intrusion even with exploitable bugs in place. The value of MAC/RBAC systems cannot be overestimated these days. One of the big problems with IoT devices is that they contain very simple linux-based operating systems without MAC/RBAC’s and without proper policy updates. An example of how well MAC/RBAC’s work, is Samsung Android devices… Samsung is known for not providing system updates, but they do provide SELinux updates with some regularity, and as long as the user doesn’t disable the “restrictive mode”, even fatal 0day bugs in the linux kernel cannot be exploited on most Samsung devices because SELinux access control is super tight. Samsung calls it “Knox”, but it’s basically just SELinux MAC with multiple unprivileged user accounts option.
SELinux was developed by the NSA. Don’t worry, it’s entirely open source and community development has taken the lead, but the NSA developers are still on the case to improve SELinux. Tomoyo was a similar project of the Japanese Secret Service, but as development was surpassed by SELinux, the Japanese Secret Service abandoned the project, which was then taken over by the community. Tomoyo is a MAC with basic access control functionality, but with a nifty self-teaching mechanism that works pretty well. Tomoyo was also forked several times, so it’s possible to chose a lightweight intelligent MAC that suits your needs as a particular user within the Tomoyo family. Generally though, most users will either use SELinux (which is the default MAC in the RedHat/Fedora family of distros), or AppArmor (which is the default MAC in the SuSE/OpenSuSE family of distros, and also the default MAC in Ubuntu). Other distros leave the choice and installation/configuration of a MAC/RBAC up to the user. For Debian, the most popular MAC/RBAC solution is probably GrSec, which is a hardening suite developed by GrSecurity (https://grsecurity.net/). SuSE/OpenSuSE has the most modular hardening functionality, because all of the parameters, from kernel to MAC/RBAC, can be set from within Yast. RedHat/Fedora/CentOS prefer the Samsung approach, they provide fixed SELinux profiles that encompass the entire system instead of per-application configs like in AppArmor. If a user wants to use the system outside of these profiles, he/she must adapt the profiles with the various tools that are made available for that, or must switch SELinux to “permissive mode”.
Any MAC/RBAC and any further hardening can be applied to any distro, these systems are not distro-specific, however, it makes sense to use the AppArmor profiles for applications made available by OpenSuSE/SuSE through SuSEStudio, even for Ubuntu, because Canonical… (yeah, it’s a recurring motif, what can I say, it’s just another reason why Ubuntu is NOT a distro for beginners…). Likewise, the most up to date SELinux profiles will be found in the Fedora repos.
Anyway, it’s always advisable to install some kind of supplemental MAC/RBAC system in your linux install. It’s not just an aid to the built-in access control mechanisms, it’s above all important to realize that no code is ever without bugs, and privilege escalation is always just around the corner, even on Linux, so you want that extra safety net of a supplemental access control system that will protect individual processes and data, even in circumstances whereby the system is accessed as root. Yes, a system is faster without SELinux or AppArmor, and a lot of people running Debian or Arch boast about the speed of their MAC/RBAC-less systems, but if you have the hardware resources to get enough performance with a MAC/RBAC, don’t hesitate but install that shit, because that shit is a damn’ good safety net against undiscovered and/or unpatched bugs.
Many people think that the fact that a linux distro asks a user to authenticate as root or as a privileged user in general (a “sudoer”), is a sign of the MAC/RBAC doing its job. That is however not the case. That is just part of the basic *nix group-based permission system, whereby every user is part of a number of groups that define his privileges in the standard system. It is of course a protection feature, but more in a management sense than in a security sense. It is also pretty easy to tweak this behaviour by preference, and there are distros that run as root by default and find that completely safe and normal. Group Policy is not a MAC system, even though it does limit access to a certain degree. Group Policy however does not go any further as comparing group privileges and file attributes basically, it is by no means an advanced security mechanism!