thiussat

Let me qualify this post as saying that I am not a security developer nor do I claim to be a security expert, or at least not an expert on the intricacies of the security aspects of the Linux kernel or the source code that comprises the technologies presented below. Most of this is data I have gleaned from other sources and from research that collates said technologies.

Logo from the PaX/Grsecurity page

Most people who know would agree that UNIX derived OS's (Linux/BSD/OpenSolaris) are the most secure OS's that are readily available to the general public. (Yes, there are other UNIXes like OS X, HP-UX, AIX but they are closed source and beyond the scope of this tutorial). While the built in UNIX multi-user environment provides a lot of protections from things like malware, these *nix OS's are far from bullet proof. They are still vulnerable to kernel or application exploits, especially if attacked by someone who knows what they're doing, unless other provisions are taken.

This post will focus on Linux and provide some definitions and an overview of technologies that can help in really locking down a Linux box. There are similar techniques and apps that do essentially the same thing for Solaris and BSD (Trusted Solaris and Trusted BSD). Even if it's overkill for 99% of desktop users, this post might be worth your while if you run an Internet facing server or are just curious about security.

The techniques used here, if implemented properly, are enough for even the most sensitive mission critical applications (though security can never be 100% guaranteed). The only way to get more security would be to use arcane OS's like perhaps XTS-400 (EAL 5) or the insanely secure GEMSOS (NSA approved and evaluated at EAL 7 - A1). But, who uses those? And who wants to use closed-source OS's?

Gentoo is the Linux flavor I use, but other flavors of Linux have similar security enhancements. Fedora, for instance, comes out of the box with some of these protections (SELinux, exec-shield, FORTIFY_SOURCE, fstack-protector, etc..). If you want a quick and easy security focused desktop Linux distro that doesn't take a lot of configuration, then Fedora is the way to go.

Now, some definitions are in order:

ASLR: Address Space Layout Randomization does what it says, it randomizes the address space (in memory) of a process. This includes the heap, stack, libraries and the executable base. ASLR is useful because it greatly hinders an attacker's ability to predict target addresses, which has to be done for some types of exploits to be successful.

DAC Discretionary Access Control. This essentially means that access controls are at a user's discretion and are not forced (the root, users, groups paradigm). The weakness of this is that a process or object with a certain set of permissions can pass that permission (even unintentionally) to another object. This is how privilege escalation attacks work. DAC is the standard UNIX security model that comes with all flavors of UNIX.

MAC: Mandatory Access Control. This is a step up from DAC and much more effective at helping stop (or greatly mitigate) exploit attacks. Since it is pretty much guaranteed that all software will have bugs and will likely be exploitable at some time or another, MAC is a way of enforcing access controls and keeping objects and processes "sandboxed." Unless the MAC policy allows object A to interact with process B, it cannot, even if exploited. So, if an attacker performs a successful root exploit on a process that is running with standard root privileges, that process cannot affect any other processes even if they also have root permissions. Essentially, the attacker will be sandboxed in and have control over a very limited portion of the system. There isn't much damage he can do with his exploited process as a result. Under the DAC model, if you exploit a root process, you usually will get full root access to the entire system. Not so with a properly configured MAC.

RBAC: Role Based Access Control This is basically a newer implementation of MAC that is based more on roles than on specific users. Instead of the policy being tailored to each user and what actions he/she can perform on processes, objects, threads, etc., these processes and objects are assigned to roles and these roles are then assigned to the users. A MAC can emulate a RBAC and vice versa. For most non-security experts, the distinction between MAC and RBAC is difficult to understand and not really all that important for our purposes. All you need to know is that most MAC implementations in Linux can also serve as RBAC's.

The Bell-La Padula Model: This is a multi-level computer security model that was created for the military and DoD in the 1970's. It's essentially the de facto standard for a MLS computer security model, even some 30+ years later. The Biba model was created later to address some shortcomings of the BLP model. These two models are what most modern security enhancements base their theory on.

Linux specific technologies:

Linux Security Modules or "LSM" is a Linux kernel framework that allows various security models to be "plugged" into the kernel. There is no standard yet, though SELinux and SMACK are two models that are officially implemented. All the rest are not part of LSM, though AppArmor does use LSM, even though it is not officially a part of the mainline kernel.

Security Enhanced Linux is a Mandatory Access Control system developed by the NSA that's based on their FLASK project. SElinux is essentially just the NSA's FLASK model being ported to the Linux kernel, hence the name. The NSA released a Linux port of FLASK mainly for input from the open-source community at large and for help in continuing the research.

Exec-shield was developed by Red Hat as a way to emulate the NX bit on x86 architectures that didn't have it built in to the CPU (most modern 64 bit CPU's have it). It later evolved into a way to implement patches to flag data memory as non-executable and non-writable and to provide ASLR and stack protection. These enhancements help stop a lot of exploits including buffer overflows, heap, format string, and shell code attacks. Exec-shield is very similar to PaX which is described below.

PaX: From the PaX homepage:

Pax is basically a kernel patch (but not a part of LSM) that provides ASLR, non-executable and non-writable memory among other protections that are intended to stop attacks on flawed software. It is similar to Exec-shield.

Grsecurity is a patch to the kernel that provides a RBAC as well as chroot jails and kernel auditing. It is usually bundled with PaX in order to provide a complete security solution. It provides a "learning mode" so that the user can avoid complex configurations like SELinux may require.

SSP/ProPolice/Stackguard: In Linux, stack smashing protection can be enabled in a couple of ways. ProPolice is implemented directly into the GNU gcc compiler while StackGuard is implemented as an extension to gcc. What stack smashing protection does is provide a level of protection against stack based buffer overflows. There are other protections available (such as PaX and exec-shield) to other types of buffer overflows (such as on the heap data).

AppArmor is a MAC implementation that, like SELinux, relies on the LSM framework. It was originally developed by Crispin Cowan and his team and was used in their security focused Immunix Linux distro. Later, Novell hired Cowan and some other members of his team and the technology was implemented into SuSE. Several years later, Cowan and his team were laid off from Novell and Cowan was hired by Microsoft where he is a member of their core security team. AppArmor is different from SELinux in that it is easier to implement and learn how to use (it has a learning mode that writes policies based on the behavior of a user over time). However, some think this makes it less powerful than SELinux.

Smack is another MAC implementation that uses the LSM framework and, like SELinux, has been included in the official kernel. The main difference in SMACK and SELinux is that SMACK focuses on being simple. SELinux is often criticized for having extraordinarily arcane syntax for configuration.


Controversy Amongst the Linux Security Community:

There are four major MAC/RBAC implementations available for Linux -- the aforementioned SELinux, AppArmor, Grsecurity, and Smack. As I said above, none are really a "standard" as of yet, but SELinux and SMACK have sort of made strides in that direction as a result of inclusion in the mainline kernel. However, there is debate about how secure the LSM framework is and whether it is even needed at all. Some experts (mainly Brad Spengler of Grsecurity) claim that LSM provides far too much access to system calls and hooks to a potential attacker who could potentially exploit LSM itself. Spengler explains:

It seems there are several other notable Linux kernel and security developers that agree with Spengler on this and have raised their concerns to Linus Torvalds and other kernel maintainers. However, Linus doesn't seem to care either way, as he admits he is not a security expert and cares more about performance of the kernel. Those who disagree with the mantra that performance should always trump security seem to be at odds with linus's viewpoint because the marginal performance increase one achieves through LSM is not enough to justify the risk of LSM itself being exploited and thus giving free reign of the kernel to an attacker. At any rate, Linus has said he will allow the community to eventually reach a consensus on which path is the correct one.

So, which to choose?

PaX vs. Exec-Shield:

They both essentially attempt to do the same thing, but they do it differently and PaX seems to do it better. Even the Exec-shield creator admits that PaX is "more complete" but he says this also comes with some trade-offs. From my experience, PaX seems to "lock-down" processes better but it also more apt to break things too (Xorg and nvidia-drivers take special care). You can see how PaX compares to exec-shield from the PaX developer's perspective here. And you can see the alternative viewpoint from the exec-shield developer here.

SELinux vs. the other MAC's:

SELinux is the most popular MAC system and some developers want to make it the standard. It certainly is effective, but it is notoriously complicated (though this is getting a lot better with the automated tools that have been developed). Grsecurity is developed by the same people who develop PaX and it is easier to use (has a learning mode). AppArmor's status seems to be uncertain due to the fact Novell laid-off the AppArmor team, but it is similar to Grsecurity in that it is easier to use than SELinux. SMACK, which is also in the kernel now, was written with simplicity in mind. From my research and reading of technical papers, many experts seem to think SELinux provides the most thorough protections.

For myself, I have chosen PaX and Grsecurity because of the fact that they are a part of hardened-Gentoo and are developed by the same people. Also, since neither are part of the LSM, I felt they were likely "safer" to use and more secure overall. SELinux is also available in Gentoo, but I chose Grsecurity since it is much easier to configure and works well with PaX.

If anyone is interested, I can provide a walk-through of how to set-up a PaX/Grsecurity enabled Gentoo install. That was going to be the focus of this post, but I saw how long it has become so I will save it for another time.

Attached Thumbnails

 

__________________

Secure Your Network With Tomato Linux Vs. Windows Security Think You Can Brute Force Long Passwords? Linux File Permissions HOWTO Secure Ubuntu With AppArmor

"I can't bring myself to try Linux Mint because they keep naming the OS after ex-girlfriends or women I've had bad run ins with. Cassandra was a sexual harassing shift manager. And Felicia was a stalker who knew how to turn a good day into a hellish experience in 0-60." -- Anub1s from BBR forums

evermooingcow

Thanks for the guide. Very good information. If you wouldn't mind I'd love to see your walk-through on enabling these features on Gentoo.

Deserves a bump anyway.

__________________
dual != duel