From Fedora Project Wiki
m (add cat)
 
(6 intermediate revisions by one other user not shown)
Line 1: Line 1:
= Introduction =
= Introduction =
On Linux® operating systems, files, directories, sockets, devices, and so on, are called objects, and processes, such as users, Mozilla® Firefox®, and the Apache HTTP Server, are called subjects. Linux operating systems use a Discretionary Access Control (DAC) system that controls how subjects interact and access objects. On systems using DAC, users control the permissions of objects (files and directories) that they own. They could, for example, make their home directories world-readable, giving subjects (users, processes, etc) access to potentially sensitive information.
On most operating systems, files, directories, sockets, devices, and so on, are called objects, and processes, such as a user running a command, the Mozilla® Firefox® application, and the Apache HTTP Server, are called subjects. Also, most operating systems use a Discretionary Access Control (DAC) system that controls how subjects interact and access objects, and how subjects interact with each other. On operating systems using DAC, users control the permissions of objects (files and directories) that they own. On Linux® operating systems, for example, users could make their home directories world-readable, giving users and subjects (processes) access to potentially sensitive information.


When using DAC, a subject launched by a user has the same access to the system as the user. When a user launches a malicious application, that application can write to, delete, and change permissions of objects in that user's home directory. This applies to objects outside of the user's home directory that the user owns, as well as any other objects that the user has write access to. The same rules apply if a user launches a flawed application.
DAC mechanisms are fundamentally inadequate for strong system security. DAC access decisions are only based on user identity and ownership, ignoring other security-relevant information such as the role of the user, the function and trustworthiness of the program, and the sensitivity and integrity of the data. Each user has complete discretion over his objects, making it impossible to enforce a system-wide security policy. Furthermore, every program run by a user inherits all of the permissions granted to the user and is free to change access to the user's objects, so no protection is provided against malicious software. Typically, only two major categories of users are supported by DAC mechanisms: completely trusted administrators and completely untrusted ordinary users. Many system services and privileged programs must run with coarse-grained privileges that far exceed their requirements, so that a flaw in any one of these programs can be exploited to obtain complete system access.[1]


The following is an example of permissions used on Linux operating systems that do not run Security-Enhanced Linux (SELinux). Use the ls -l command to view object (such as a file) permissions:  
The following is an example of permissions used on Linux operating systems that do not run Security-Enhanced Linux (SELinux). Use the ls -l command to view object (such as a file) permissions:  
Line 10: Line 10:
</pre>
</pre>


The first three permission bits, rwx, control the access the Linux user1 user (in this case, the owner) has to the file1 object. The next three permission bits, rw-, control the access the Linux group1 group has to the file1 object. The last three permission bits, r--, control the access everyone else has to the file1 object. This includes all subjects (such as users and processes). By default, when a new object (such as a file) is created, everyone has read permissions. If objects have read permissions, and their parent folder allows everyone read and execute permissions, all subjects (users and processes) have read and execute access to these objects. This is not desirable. Note: on Fedora 10, by default, home directories only allow read, write, and execute permissions to the owner. Other subjects, excluding the Linux root user, do not have access. Also, the permissions in these examples may differ from your system. These examples purposely change the permissions to differentiate between the permissions of the owner, group, and everyone else.
The first three permission bits, rwx, control the access the Linux user1 user (in this case, the owner) has to the file1 object. The next three permission bits, rw-, control the access the Linux group1 group has to the file1 object. The last three permission bits, r--, control the access everyone else has to the file1 object. This includes all subjects (processes) and users. On Fedora 10, if the default umask (0002) is used, when a new object (such as a file) is created, everyone has read permissions. If objects have read permissions, and their parent folder allows everyone read and execute permissions, all subjects and users have read and execute access to these objects. This is not desirable. Note: on Fedora 10, by default, home directories only allow read, write, and execute permissions to the owner. Other subjects and Linux users, excluding the Linux root user, do not have access. Also, the permissions in these examples may differ from your system. These examples purposely change the permissions to differentiate between the permissions of the owner, group, and everyone else.


Security-Enhanced Linux (SELinux) adds Mandatory Access Control (MAC) to the Linux kernel, and is enabled by default in Fedora. MAC allows administratively-defined policies, such as SELinux policy, to be enforced system-wide, on both subjects (such as users and processes) and objects (such as files). This controls the interaction between subjects and objects, as well as the interaction between subjects. On systems running SELinux, subjects and objects are labeled with an SELinux context that contains additional information, such as an SELinux user, role, and type. When running SELinux, all of this information is used to make access control decisions, as opposed to DAC systems, that control access based on Linux user and group IDs. DAC provides little protections from malicious and flawed applications, and since permissions are controlled at user discretion, DAC does not allow system-wide security policies to be enforced.
Security-Enhanced Linux (SELinux) adds Mandatory Access Control (MAC) to the Linux kernel, and is enabled by default in Fedora. A general purpose MAC architecture needs the ability to enforce an administratively-set security policy over all subjects and objects in the system, basing decisions on labels containing a variety of security-relevant information. When properly implemented, it enables a system to adequately defend itself and offers critical support for application security by protecting against the tampering with, and bypassing of, secured applications. MAC provides strong separation of applications that permits the safe execution of untrustworthy applications. Its ability to limit the privileges associated with executing processes limits the scope of potential damage that can result from the exploitation of vulnerabilities in applications and system services. MAC enables information to be protected from legitimate users with limited authorization as well as from authorized users who have unwittingly executed malicious applications. The ability for the system to do these types of things is necessary before the construction of secure systems will be possible.[2]


The following is an example of the additional SELinux information used on Linux operating systems that use SELinux. This information is called the SELinux context, and is viewed using the ls -Z command:  
The following is an example of the additional SELinux information used on Linux operating systems that use SELinux. This information is called the SELinux context, and is viewed using the ls -Z command:  
Line 20: Line 20:
</pre>
</pre>


In this example, SELinux provides a user (unconfined_u), a role (object_r), a type (user_home_t), and a category (s0). This information is used to make access control decisions. On DAC systems, only the Linux user and group ID are used to make access decisions. SELinux allow and denying rules are checked after DAC rules. SELinux allow and deny rules are not used if DAC rules deny access first.
In this example, SELinux provides a user (unconfined_u), a role (object_r), a type (user_home_t), and a level (s0). This information is used to make access control decisions. On DAC systems, access is controlled based on Linux user and group IDs. SELinux allow rules are checked after DAC rules. SELinux allow rules are not used if DAC rules deny access first.


'''Linux and SELinux users'''
'''Linux and SELinux users'''


On systems running SELinux, there are standard Linux users, as well as SELinux users. SELinux users are part of the SELinux context (the additional labels on subjects and objects), and can be mapped to Linux users. To avoid confusion, this guide uses "Linux user" and "SELinux user" to differentiate between the two.
On Linux operating systems that run SELinux, there are Linux users as well as SELinux users. SELinux users are part of SELinux policy. Linux users are mapped to SElinux users. To avoid confusion, this guide uses "Linux user" and "SELinux user" to differentiate between the two.


'''SELinux on other Operating Systems'''
'''SELinux on other Operating Systems'''
Line 43: Line 43:
SELinux provides:
SELinux provides:


* An additional layer of security: a system where subjects (processes) are separated from each other by running in their own domains, and rules define how subjects interact and access objects (such as files), as well as how subjects interact with each other. Actions, such as a subject opening an object, are only allowed if a rule exists that specifically allows it.
* All subjects and objects are labeled with a type. Subjects (processes) are separated from each other by running in their own domains, and rules define how subjects interact and access objects (such as files), as well as how subjects interact with each other. Access is only allowed if a rule exists that specifically allows it.


* Fine-grained access control. Stepping beyond traditional UNIX® permissions that are controlled at user discretion, SELinux access decisions are based on all available information, such as an SELinux user, role, and type. SELinux allow and deny rules are not used if DAC rules deny access first.
* Fine-grained access control. Stepping beyond traditional UNIX® permissions that are controlled at user discretion and based on Linux user and group IDs, SELinux access decisions are based on all available information, such as an SELinux user, role, and type.


* Type Enforcement®. All subjects and objects are labeled with a type. Rules define how types interact and access each other. Access is only allowed if a rule exists that specifically allows it.
* SELinux policy is administratively-defined, enforced system-wide, and is not set at user discretion.


* Prevention against privilege escalation. Since subjects run in domains, and are therefore separated from each other, and rules determine how subjects access objects and other subjects, if a service is compromised, the attacker only has access to the normal functions of that service, and to files that the service has been configured to have access to. For example, if the Apache HTTP Server is compromised, an attacker is unable to read files in user home directories, unless a specific rule was added or configured to allow such access.
* Reduced vulnerability to privilege escalation attacks. One example: since subjects run in domains, and are therefore separated from each other, and rules determine how subjects access objects and other subjects, if a service is compromised, the attacker only has access to the normal functions of that service, and to objects that the service has been configured to have access to. For example, if the Apache HTTP Server is compromised, an attacker is unable to read objects in user home directories, unless a specific rule was added or configured to allow such access.
 
Other goals to which SELinux can be applied include enforcing data confidentiality and integrity, protecting privileged subjects from untrustworthy inputs, and ensuring the invocation of critical processing.[3]


SELinux is not:  
SELinux is not:  
Line 59: Line 61:
* An all-in-one security solution.  
* An all-in-one security solution.  


SELinux is an addition to DAC rules. It is designed to enhance existing security solutions, not replace them. Even when running SELinux, continue to follow good security practices, such as keeping software up-to-date, using hard-to-guess passwords, firewalls, and so on.
SELinux is designed to enhance existing security solutions, not replace them. Even when running SELinux, continue to follow good security practices, such as keeping software up-to-date, using hard-to-guess passwords, firewalls, and so on.


= Examples =
= Examples =
Line 69: Line 71:
* Confining users: SELinux can confine Linux users. A number of restricted SELinux users exist. Linux users can be mapped to restricted SELinux users to take advantage of confined SELinux users. For example, mapping a Linux user account to the SELinux user_u user, results in a Linux user that is not able to run (unless configured otherwise) set user ID (setuid) applications, such as /usr/bin/sudo and su. Also, you can disable the execution of objects in user home directories for Linux users that are mapped to the SELinux user_u user. If configured, this prevents users from executing malicious files, that they may have downloaded from the Internet, from their home directories.
* Confining users: SELinux can confine Linux users. A number of restricted SELinux users exist. Linux users can be mapped to restricted SELinux users to take advantage of confined SELinux users. For example, mapping a Linux user account to the SELinux user_u user, results in a Linux user that is not able to run (unless configured otherwise) set user ID (setuid) applications, such as /usr/bin/sudo and su. Also, you can disable the execution of objects in user home directories for Linux users that are mapped to the SELinux user_u user. If configured, this prevents users from executing malicious files, that they may have downloaded from the Internet, from their home directories.


* Subject (such as a process) separation. Subjects run in their own domains. This prevents other subjects from accessing objects used by other subjects, as well as subjects accessing other subjects. For example, when running SELinux, unless otherwise configured, an attacker can not compromise a Samba server, and then use that Samba server to read and write to objects used by other subjects, such as files comprising a website that is read by the Apache HTTP server.
* Subject (process) separation. Subjects run in their own domains. This prevents other subjects from accessing objects used by other subjects, as well as subjects accessing other subjects. For example, when running SELinux, unless otherwise configured, an attacker can not compromise a Samba server, and then use that Samba server to read and write to objects used by other subjects, such as files comprising a website that is read by the Apache HTTP server.
 
* Help limit the damage done by configuration mistakes. [http://en.wikipedia.org/wiki/Domain_Name_System Domain Name System (DNS)] servers can replicate information between each other. This is known as a zone transfer. Attackers can use zone transfers to update DNS servers with false information. When running the [http://www.isc.org/index.pl?/sw/bind/index.php Berkeley Internet Name Domain (BIND)] DNS server on Fedora 10, even if an administrator forgets to limit which servers can perform a zone transfer, the default SELinux policy prevents zone files[4] from being updated by zone transfers, the BIND named daemon, and any other subjects.
 
* Refer to the [http://www.redhatmagazine.com/ Red Hat Magazine] article, [http://www.redhatmagazine.com/2008/02/26/risk-report-three-years-of-red-hat-enterprise-linux-4/ Risk report: Three years of Red Hat Enterprise Linux 4][5], for exploits against PHP and an exploit against MySQL, which were not successful due to the default SELinux targeted policy for the Apache HTTP Server and MySQL on Red Hat Enterprise Linux 4.
 
* Refer to the [http://www.linuxworld.com/ LinuxWorld.com] article, [http://www.linuxworld.com/news/2008/022408-selinux.html?page=1 A seatbelt for server software: SELinux blocks real-world exploits], for background information about SELinux, and information about various exploits that SELinux has prevented.[6]
 
* Refer to James Morris's [http://james-morris.livejournal.com/25421.html SELinux mitigates remote root vulnerability in OpenPegasus] blog entry, for information about an exploit in [http://www.openpegasus.org/ OpenPegasus] that was mitigated by SELinux as shipped with Red Hat Enterprise Linux 4 and 5.


* Help limit the damage done by configuration mistakes. An administrator may forget to limit zone transfers when running ISC BIND; however, the default SELinux context for zone files does not allow them to be updated by zone transfers, or written to by named, the ISC BIND daemon, and other subjects.
The [http://www.tresys.com/ Tresys Technology] website has an [http://www.tresys.com/innovation.php SELinux Mitigation News] section (on the right-hand side), that lists recent exploits that have been mitigated or prevented by SELinux.  


= SELinux Architecture and Performance =
= SELinux Architecture and Performance =


SELinux is a Linux kernel module. Part of this module is the SELinux security server. The security server contains policy rules that define what access is allowed. When a subject attempts to interact with an object, for example, a process opening a file, a hook in the Linux kernel intercepts the system call the process makes to open the file. The hook communicates with the security server to check if access should be allowed or denied. Decisions made by the security server are cached by an Access Vector Cache (AVC). This decreases how often SELinux rules in the security server need to be checked, which increases performance. SELinux has no effect if DAC rules deny access first.
SELinux is a Linux security module that is built into the Linux kernel. SELinux is driven by loadable policy rules. When security-relevant access is taking place, such as when a subject attempts to open an object, the operation is intercepted in the kernel by SELinux. If an SELinux policy rule allows the operation, it continues, otherwise, the operation is blocked and the subject receives an error.
 
SELinux decisions, such as allowing or disallowing access, are cached. This cache is known as the Access Vector Cache (AVC). This decreases how often SELinux policy rules need to be checked, which increases performance. SELinux policy rules have no affect if DAC rules deny access first.
 
SELinux has three modes: permissive, enforcing, and disabled. [ please insert real and accurate information this time :( ]
 
 
 
[1] "Integrating Flexible Support for Security Policies into the Linux Operating System", by Peter Loscocco and Stephen Smalley. This paper was originally prepared for the National Security Agency and is, consequently, in the public domain. Refer to the [http://www.nsa.gov/selinux/papers/freenix01/freenix01.html original paper] for details and the document as it was first released. Any edits and changes were done by Murray McAllister.
 
[2] "Meeting Critical Security Objectives with Security-Enhanced Linux", by Peter Loscocco and Stephen Smalley. This paper was originally prepared for the National Security Agency and is, consequently, in the public domain. Refer to the [http://www.nsa.gov/selinux/papers/ottawa01/index.html original paper] for details and the document as it was first released. Any edits and changes were done by Murray McAllister.
 
[3] Smalley, Stephen. 'Re: user guide draft: "Introduction" review'. Email to Murray McAllister, 27 August 2008. Any edits were done by Murray McAllister.
 
[4] Text files that include information, such as hostname to IP address mappings, that are used by DNS servers.
 
[5] Cox, Mark. "Risk report: Three years of Red Hat Enterprise Linux 4". Published 26 February 2008. Accessed 28 August 2008: <http://www.redhatmagazine.com/2008/02/26/risk-report-three-years-of-red-hat-enterprise-linux-4/>.
 
[6] Marti, Don. "A seatbelt for server software: SELinux blocks real-world exploits". Published 24 February 2008. Accessed 28 August 2008: <http://www.linuxworld.com/news/2008/022408-selinux.html?page=1>.


SELinux has three modes: permissive, enforcing, and disabled. [ please insert real and accurate information this time :( ]
[[Category:SELinux docs]]

Latest revision as of 00:48, 28 February 2009

Introduction

On most operating systems, files, directories, sockets, devices, and so on, are called objects, and processes, such as a user running a command, the Mozilla® Firefox® application, and the Apache HTTP Server, are called subjects. Also, most operating systems use a Discretionary Access Control (DAC) system that controls how subjects interact and access objects, and how subjects interact with each other. On operating systems using DAC, users control the permissions of objects (files and directories) that they own. On Linux® operating systems, for example, users could make their home directories world-readable, giving users and subjects (processes) access to potentially sensitive information.

DAC mechanisms are fundamentally inadequate for strong system security. DAC access decisions are only based on user identity and ownership, ignoring other security-relevant information such as the role of the user, the function and trustworthiness of the program, and the sensitivity and integrity of the data. Each user has complete discretion over his objects, making it impossible to enforce a system-wide security policy. Furthermore, every program run by a user inherits all of the permissions granted to the user and is free to change access to the user's objects, so no protection is provided against malicious software. Typically, only two major categories of users are supported by DAC mechanisms: completely trusted administrators and completely untrusted ordinary users. Many system services and privileged programs must run with coarse-grained privileges that far exceed their requirements, so that a flaw in any one of these programs can be exploited to obtain complete system access.[1]

The following is an example of permissions used on Linux operating systems that do not run Security-Enhanced Linux (SELinux). Use the ls -l command to view object (such as a file) permissions: 

-rwxrw-r-- 1 user1 group1 0 Aug 18 10:08 file1

The first three permission bits, rwx, control the access the Linux user1 user (in this case, the owner) has to the file1 object. The next three permission bits, rw-, control the access the Linux group1 group has to the file1 object. The last three permission bits, r--, control the access everyone else has to the file1 object. This includes all subjects (processes) and users. On Fedora 10, if the default umask (0002) is used, when a new object (such as a file) is created, everyone has read permissions. If objects have read permissions, and their parent folder allows everyone read and execute permissions, all subjects and users have read and execute access to these objects. This is not desirable. Note: on Fedora 10, by default, home directories only allow read, write, and execute permissions to the owner. Other subjects and Linux users, excluding the Linux root user, do not have access. Also, the permissions in these examples may differ from your system. These examples purposely change the permissions to differentiate between the permissions of the owner, group, and everyone else.

Security-Enhanced Linux (SELinux) adds Mandatory Access Control (MAC) to the Linux kernel, and is enabled by default in Fedora. A general purpose MAC architecture needs the ability to enforce an administratively-set security policy over all subjects and objects in the system, basing decisions on labels containing a variety of security-relevant information. When properly implemented, it enables a system to adequately defend itself and offers critical support for application security by protecting against the tampering with, and bypassing of, secured applications. MAC provides strong separation of applications that permits the safe execution of untrustworthy applications. Its ability to limit the privileges associated with executing processes limits the scope of potential damage that can result from the exploitation of vulnerabilities in applications and system services. MAC enables information to be protected from legitimate users with limited authorization as well as from authorized users who have unwittingly executed malicious applications. The ability for the system to do these types of things is necessary before the construction of secure systems will be possible.[2]

The following is an example of the additional SELinux information used on Linux operating systems that use SELinux. This information is called the SELinux context, and is viewed using the ls -Z command: 

-rwxrw-r--  user1 group1 unconfined_u:object_r:user_home_t:s0      file1

In this example, SELinux provides a user (unconfined_u), a role (object_r), a type (user_home_t), and a level (s0). This information is used to make access control decisions. On DAC systems, access is controlled based on Linux user and group IDs. SELinux allow rules are checked after DAC rules. SELinux allow rules are not used if DAC rules deny access first.

Linux and SELinux users

On Linux operating systems that run SELinux, there are Linux users as well as SELinux users. SELinux users are part of SELinux policy. Linux users are mapped to SElinux users. To avoid confusion, this guide uses "Linux user" and "SELinux user" to differentiate between the two.

SELinux on other Operating Systems Refer to the following for information about running SELinux on operating systems:

Refer to <http://fedoraproject.org/wiki/SELinux/FAQ> for further information about SELinux on Fedora.

Benefits of running SELinux

SELinux provides:

  • All subjects and objects are labeled with a type. Subjects (processes) are separated from each other by running in their own domains, and rules define how subjects interact and access objects (such as files), as well as how subjects interact with each other. Access is only allowed if a rule exists that specifically allows it.
  • Fine-grained access control. Stepping beyond traditional UNIX® permissions that are controlled at user discretion and based on Linux user and group IDs, SELinux access decisions are based on all available information, such as an SELinux user, role, and type.
  • SELinux policy is administratively-defined, enforced system-wide, and is not set at user discretion.
  • Reduced vulnerability to privilege escalation attacks. One example: since subjects run in domains, and are therefore separated from each other, and rules determine how subjects access objects and other subjects, if a service is compromised, the attacker only has access to the normal functions of that service, and to objects that the service has been configured to have access to. For example, if the Apache HTTP Server is compromised, an attacker is unable to read objects in user home directories, unless a specific rule was added or configured to allow such access.

Other goals to which SELinux can be applied include enforcing data confidentiality and integrity, protecting privileged subjects from untrustworthy inputs, and ensuring the invocation of critical processing.[3]

SELinux is not:

  • Antivirus software.
  • A replacement for passwords, firewalls, or other security systems.
  • An all-in-one security solution.

SELinux is designed to enhance existing security solutions, not replace them. Even when running SELinux, continue to follow good security practices, such as keeping software up-to-date, using hard-to-guess passwords, firewalls, and so on.

Examples

The following examples demonstrate how SELinux increases security:

  • The default action is deny. If a rule does not exist to allow a subject access to an object, or a subject access to another subject, access is denied.
  • Confining users: SELinux can confine Linux users. A number of restricted SELinux users exist. Linux users can be mapped to restricted SELinux users to take advantage of confined SELinux users. For example, mapping a Linux user account to the SELinux user_u user, results in a Linux user that is not able to run (unless configured otherwise) set user ID (setuid) applications, such as /usr/bin/sudo and su. Also, you can disable the execution of objects in user home directories for Linux users that are mapped to the SELinux user_u user. If configured, this prevents users from executing malicious files, that they may have downloaded from the Internet, from their home directories.
  • Subject (process) separation. Subjects run in their own domains. This prevents other subjects from accessing objects used by other subjects, as well as subjects accessing other subjects. For example, when running SELinux, unless otherwise configured, an attacker can not compromise a Samba server, and then use that Samba server to read and write to objects used by other subjects, such as files comprising a website that is read by the Apache HTTP server.
  • Help limit the damage done by configuration mistakes. Domain Name System (DNS) servers can replicate information between each other. This is known as a zone transfer. Attackers can use zone transfers to update DNS servers with false information. When running the Berkeley Internet Name Domain (BIND) DNS server on Fedora 10, even if an administrator forgets to limit which servers can perform a zone transfer, the default SELinux policy prevents zone files[4] from being updated by zone transfers, the BIND named daemon, and any other subjects.

The Tresys Technology website has an SELinux Mitigation News section (on the right-hand side), that lists recent exploits that have been mitigated or prevented by SELinux.

SELinux Architecture and Performance

SELinux is a Linux security module that is built into the Linux kernel. SELinux is driven by loadable policy rules. When security-relevant access is taking place, such as when a subject attempts to open an object, the operation is intercepted in the kernel by SELinux. If an SELinux policy rule allows the operation, it continues, otherwise, the operation is blocked and the subject receives an error.

SELinux decisions, such as allowing or disallowing access, are cached. This cache is known as the Access Vector Cache (AVC). This decreases how often SELinux policy rules need to be checked, which increases performance. SELinux policy rules have no affect if DAC rules deny access first.

SELinux has three modes: permissive, enforcing, and disabled. [ please insert real and accurate information this time :( ]


[1] "Integrating Flexible Support for Security Policies into the Linux Operating System", by Peter Loscocco and Stephen Smalley. This paper was originally prepared for the National Security Agency and is, consequently, in the public domain. Refer to the original paper for details and the document as it was first released. Any edits and changes were done by Murray McAllister.

[2] "Meeting Critical Security Objectives with Security-Enhanced Linux", by Peter Loscocco and Stephen Smalley. This paper was originally prepared for the National Security Agency and is, consequently, in the public domain. Refer to the original paper for details and the document as it was first released. Any edits and changes were done by Murray McAllister.

[3] Smalley, Stephen. 'Re: user guide draft: "Introduction" review'. Email to Murray McAllister, 27 August 2008. Any edits were done by Murray McAllister.

[4] Text files that include information, such as hostname to IP address mappings, that are used by DNS servers.

[5] Cox, Mark. "Risk report: Three years of Red Hat Enterprise Linux 4". Published 26 February 2008. Accessed 28 August 2008: <http://www.redhatmagazine.com/2008/02/26/risk-report-three-years-of-red-hat-enterprise-linux-4/>.

[6] Marti, Don. "A seatbelt for server software: SELinux blocks real-world exploits". Published 24 February 2008. Accessed 28 August 2008: <http://www.linuxworld.com/news/2008/022408-selinux.html?page=1>.

Retrieved from "https://fedoraproject.org/w/index.php?title=Docs/Drafts/SELinux_User_Guide/SELinux_Implementation_Phase/Introduction&oldid=83980"