Security - Enhanced Linux Security - Enhanced Linux ( SELinux ) is a Linux kernel security module that provides the mechanism for supporting access control security policies , including United States Department of Defense - style mandatory access control s ( MAC ) . It is a set of kernel modifications and user - space tools that can be added to various Linux distributions . Its architecture strives to separate enforcement of security decisions from the security policy itself and streamlines the volume of software charged with security policy enforcement . The key concepts underlying SELinux can be traced to several earlier projects by the United States National Security Agency . It has been integrated into the mainline Linux kernel since version 2 . 6 , on 8 August 2003 . Overview . The United States National Security Agency ( NSA ) , the original primary developer of SELinux , released the first version to the open source development community under the GNU GPL on December 22 , 2000 . The software merged into the mainline Linux kernel 2 . 6 . 0 - test3 , released on 8 August 2003 . Other significant contributors include Network Associates , Red Hat , Secure Computing Corporation , Tresys Technology , and Trusted Computer Solutions . Experimental ports of the FLASK / TE implementation have been made available via the TrustedBSD Project for the FreeBSD and Darwin operating systems . From NSA Security - enhanced Linux Team : " ( SELinux has been integrated into version 2 . 6 series of the Linux kernel , and separate patches are now unnecessary ; the above is a historical quotation . ) " Security - Enhanced Linux implements the Flux Advanced Security Kernel ( FLASK ) integrated in some versions of the Linux kernel with a number of utilities designed to demonstrate the value of mandatory access controls to the Linux community and how such controls could be added to Linux . Such a kernel contains architectural components prototyped in the Fluke operating system . These provide general support for enforcing many kinds of mandatory access control policies , including those based on the concepts of type enforcement , role - based access control , and multilevel security . FLASK , in turn , was based on DTOS , a Mach - derived " Distributed Trusted Operating System " , as well as Trusted Mach , a research project from Trusted Information Systems that had an influence on the design and implementation of DTOS . A Linux kernel integrating SELinux enforces mandatory access - control policies that confine user programs and system servers to the minimum amount of privilege they require to do their jobs . This reduces or eliminates the ability of these programs and daemons to cause harm when compromised ( via buffer overflows or misconfigurations , for example ) . This confinement mechanism operates independently of the traditional Linux ( discretionary ) access control mechanisms . It has no concept of a " root " super - user , and does not share the well - known shortcomings of the traditional Linux security mechanisms ( such as a dependence on setuid / setgid binaries ) . The security of an " unmodified " Linux system ( a system without SELinux ) depends on the correctness of the kernel , of all the privileged applications , and of each of their configurations . A problem in any one of these areas may allow the compromise of the entire system . In contrast , the security of a " modified " system ( based on an SELinux kernel ) depends primarily on the correctness of the kernel and its security - policy configuration . While problems with the correctness or configuration of applications may allow the limited compromise of individual user programs and system daemons , they do not pose a threat to the security of other user programs and system daemons or to the security of the system as a whole . From a purist perspective , SELinux provides a hybrid of concepts and capabilities drawn from mandatory access controls , mandatory integrity controls , role - based access control ( RBAC ) , and type enforcement architecture . Third - party tools enable one to build a variety of security policies . Users , policies and security contexts . SELinux users and roles are not related to the actual system users and roles . For every current user or process , SELinux assigns a three string context consisting of a role , user name , and domain ( or type ) . This system is more flexible than normally required : as a rule , most of the real users share the same SELinux username , and all access control is managed through the third tag , the domain . Circumstance for when the user is allowed to get into a certain domain must be configured in the policies . The command " runcon " allows for the launching of a process into an explicitly specified context ( user , role and domain ) , but SELinux may deny the transition if it is not approved by the policy configuration . Files , network ports , and other hardware also have an SELinux context , consisting of a name , role ( seldom used ) , and type . In case of the file systems , mapping between files and the security contexts is called labeling . The labeling is defined in policy files but can also be manually adjusted without changing the policies . Hardware types are quite detailed , for instance , bin _ t ( all files in the folder / bin ) or postgresql _ port _ t ( PostgreSQL port , 5432 ) . The SELinux context for a remote file system can be specified explicitly at mount time . SELinux adds the - Z switch to the shell commands " ls " , " ps " , and some others , allowing the security context of the files or process to be seen . Typical policy rules often consist of explicit permissions ; which domains the user must possess to perform certain actions with the given target ( read , execute , or , in case of network port , bind or connect ) , and so on . More complex mappings are also possible , involving roles and security levels . A typical policy consists of a mapping ( labeling ) file , a rule file , and an interface file , that define the domain transition . These three files must be compiled together with the SELinux tools to produce a single policy file . The resulting policy file can be loaded into the kernel , making it active . Loading and unloading policies does not require a reboot . The policy files are either hand written or can be generated from the more user friendly SELinux management tool . They are normally tested in permissive mode first , where violations are logged but allowed . The " audit2allow " tool can be used later to produce additional rules that extend the policy to allow all legitimate activities of the application being confined . Usage . SELinux can potentially control which activities a system allows each user , process and daemon , with very precise specifications . However , it is mostly used to confine daemons like database engines or web servers that have more clearly - defined data access and activity rights . This limits potential harm from a confined daemon that becomes compromised . Ordinary user - processes often run in the unconfined domain , not restricted by SELinux but still restricted by the classic Linux access rights . Command - line utilities include : codice _ 1 , codice _ 2 , codice _ 3 , codice _ 4 , codice _ 5 , codice _ 6 , codice _ 7 , codice _ 8 , codice _ 9 , codice _ 10 , codice _ 11 , codice _ 12 codice _ 13 , codice _ 8 , codice _ 7 , codice _ 16 , codice _ 17 , codice _ 18 , codice _ 19 , codice _ 20 , codice _ 21 , codice _ 22 , codice _ 23 and codice _ 24 . Usage examples . To put SELinux into enforcing mode : To query the SELinux status : Implementations . SELinux is available with commercial support as part of Red Hat Enterprise Linux ( RHEL ) version 4 and all future releases . This presence is also reflected in corresponding versions of CentOS and Scientific Linux . The supported policy in RHEL4 is the targeted policy which aims for maximum ease of use and thus is not as restrictive as it might be . Future versions of RHEL are planned to have more targets in the targeted policy which will mean more restrictive policies . In free community supported GNU / Linux distributions , Fedora was one of the earliest adopters , including support for it by default since Fedora Core 2 . Other distributions include support for it such as Debian as of the etch release and Ubuntu as of 8 . 04 Hardy Heron . As of version 11 . 1 , openSUSE contains SELinux “ basic enablement ” . SUSE Linux Enterprise 11 features SELinux as a “ technology preview ” . The earliest work directed toward standardizing an approach toward provision of mandatory and discretionary access controls ( MAC and DAC ) within a UNIX ( more precisely , POSIX ) computing environment can be attributed to the National Security Agency ' s Trusted UNIX ( TRUSIX ) Working Group , which met from 1987 to 1991 and published one Rainbow Book ( # 020A ) and produced a formal model and associated evaluation evidence prototype ( # 020B ) that was ultimately unpublished . It was sponsored by Chet Coates and Mario Tinto of the NSA ' s National Computer Security Center , and managed by Dr . Charles Testa and Bruce Wilner of Infosystems Technology ( Greenbelt , Maryland ; later , Falls Church , Virginia ) , the crucial architects of the TRUSIX project , and members of its Modeling Subcommittee – Steve Bunch , Dr . Frank Knowles , Dr . J . Eric Roskos , Larry Wehr , and Bruce Wilner . Their efforts , particularly as critics of the less technically profound work of the TRUSIX Access Control List ( ACL ) Subcommittee , survive in the IEEE POSIX 1003 . 6 " security extensions for portable operating systems environments " specification . Comparison with AppArmor . SELinux represents one of several possible approaches to the problem of restricting the actions that installed software can take . Another popular alternative , available on Novell ' s SuSE Linux and Canonical ' s Ubuntu platform , is called AppArmor . AppArmor was developed as a component to the now - defunct Immunix Linux platform . Because AppArmor and SELinux differ radically from one another , they form distinct alternatives for software control . Whereas SELinux re - invents certain concepts in order to provide access to a more expressive set of policy choices , AppArmor was designed to be simple by extending the same administrative semantics used for DAC up to the mandatory access control level . There are several key differences : Other systems . Isolation of processes can also be accomplished by mechanisms like virtualization ; the OLPC project , for example , in its first implementation sandboxed individual applications in lightweight Vserver s . Security - Enhanced Android . The NSA have adopted some of the SE Linux concepts in Security - Enhanced Android .