Hacks From Pax: Security Enhanced Linux and Mandatory Access Control

    Date10 Oct 2005
    Posted ByBrittany Day
    Security Enhanced Linux, or SELinux, is an exciting security project that is reaching maturity and poised to revolutionize the way Linux security administration is performed. Originally developed by the National Security Agency and released as an open source project, but now breaking into the mainstream in Red Hat, Fedora, Gentoo, and the new release of EnGarde Secure Linux 3.0, it incorporates Mandatory Access Control into a base Linux system. This is a revolutionary advance, but is also very different from the standard Linux security model. This week in Hacks From Pax, I'll provide a basic introduction to the philosophy behind SELinux, and explain how it can add a powerful layer of security to your Linux system.

    Discretionary Access Control vs. Mandatory Access Control

    Standard Linux file permissions use the Discretionary Access Control (DAC) model. Under DAC, files are owned by a user and that user has full control over them, including the ability to grant access permissions to other users. The root account has full control over every file on the entire system. An attacker who penetrates an account can do anything with the files owned by that user. For example, an attacker who compromises a web server has full control over all files owned by the webserver account. Worse, if an application runs under the context of the root user, an attacker penetrating it now has full control over the entire system.

    SELinux supplements Discretionary Access Control with Mandatory Access Control (MAC). Under MAC, the adminstrator writes a security policy that defines access rights for all users and applications. MAC in effect provides each application with a virtual sandbox that only allows the application to perform the tasks it is designed for and explicitly allowed in the security policy to perform. For example, the webserver process may only be able to read web published files and serve them on a specified network port. An attacker penetrating it will not be able to perform any activities not expressly permitted to the process by the security policy, even if the process is running as the root user. Files are assigned a security context that determines what specific processes can do with them, and the allowable actions are much more finely grained than the standard Unix read/write/execute controls. For example, a web served file would have a context allowing the apache process to read it but not execute or make changes to it, while the log files would be appendable but not readable or otherwise changeable by apache. Network ports are also assigned a context, which can prevent penetrated applications from using ports not permitted to them by security policy. Standard Unix permissions are still present on the system, and will be consulted before the SELinux policy when access attempts are made. If the standard permissions would deny access, access is simply denied and SELinux is not consulted at all. If the standard file permissions would allow access, the SELinux policy is consulted and access is either allowed or denied based on the security contexts of the source process and the targeted object.

    The SELinux Revolution

    The contrast between this approach and the approach of most security products in the anti-virus and intrusion prevention and detection markets could not be more stark. Anti-virus and IDS/IPS systems based on signatures are reactive, operating only on known threats, which is why zero-day exploits are so prized by malware authors. You can compare these products to firewalls with a default "allow any" rule, and many specific "deny" rules. This is a losing battle, as the quantity of malware keeps increasing at an exponential rate and vendors and their customers fight a losing battle to keep up. Any newly discovered security flaw will have a window of vulnerability between the exploit's release and the signature being added and propagated to the end user.

    SELinux, on the other hand, can be compared to a firewall with a default "deny any" rule, and a set of "allow" rules to only permit actions that are necessary for proper system operation. Malware or hack attempts that penetrate an application and attempt to escalate privileges can be stopped dead or limited to the point of near uselessness by the SELinux security policy, protecting the system regardless of whether the threat is well known or it is a brand new zero-day attack. SELinux does not need to know anything about the exploit to protect the system, it ony needs to know what proper operations should be allowed.

    This of course does not mean SELinux is a security holy grail. It requires knowledgeable administrators configuring its security policy, and should be used in concert with proper standard DAC unix permissions and tightly configured firewalls. SELinux adds another powerful layer of security to a system, however, and represents a major step forward in the state of the art of highly secure systems. Open source software is sometimes tarred as a follower and not an innovator by computer industry pundits, but SELinux is an example of open source leading the way in its adoption of a revolutionary change in the way systems are secured.
    Pax Dickinson has over ten years of experience in systems administration and software development on a wide variety of hardware and software platforms. He is currently employed by Guardian Digital as a systems programmer where he develops and implements security solutions using EnGarde Secure Linux. His experience includes UNIX and Windows systems engineering and support at Prudential Insurance, Guardian Life Insurance, Philips Electronics and a wide variety of small business consulting roles.

    You are not authorised to post comments.

    Comments powered by CComment

    LinuxSecurity Poll

    What do you think of the articles on LinuxSecurity?

    No answer selected. Please try again.
    Please select either existing option or enter your own, however not both.
    Please select minimum 0 answer(s) and maximum 3 answer(s).
    [{"id":"87","title":"Excellent, don't change a thing!","votes":"25","type":"x","order":"1","pct":54.35,"resources":[]},{"id":"88","title":"Should be more technical","votes":"5","type":"x","order":"2","pct":10.87,"resources":[]},{"id":"89","title":"Should include more HOWTOs","votes":"16","type":"x","order":"3","pct":34.78,"resources":[]}]["#ff5b00","#4ac0f2","#b80028","#eef66c","#60bb22","#b96a9a","#62c2cc"]["rgba(255,91,0,0.7)","rgba(74,192,242,0.7)","rgba(184,0,40,0.7)","rgba(238,246,108,0.7)","rgba(96,187,34,0.7)","rgba(185,106,154,0.7)","rgba(98,194,204,0.7)"]350

    We use cookies to provide and improve our services. By using our site, you consent to our Cookie Policy.