diff options
Diffstat (limited to 'xml/selinux/hb-intro-concepts.xml')
| -rw-r--r-- | xml/selinux/hb-intro-concepts.xml | 910 |
1 files changed, 0 insertions, 910 deletions
diff --git a/xml/selinux/hb-intro-concepts.xml b/xml/selinux/hb-intro-concepts.xml deleted file mode 100644 index bc6f4c1..0000000 --- a/xml/selinux/hb-intro-concepts.xml +++ /dev/null @@ -1,910 +0,0 @@ -<?xml version='1.0' encoding='UTF-8'?> -<!DOCTYPE sections SYSTEM "/dtd/book.dtd"> - -<!-- The content of this document is licensed under the CC-BY-SA license --> -<!-- See http://creativecommons.org/licenses/by-sa/1.0 --> - -<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-intro-concepts.xml,v 1.4 2011/06/07 19:46:52 klondike Exp $ --> - -<sections> -<version>6</version> -<date>2012-04-29</date> - -<section> -<title>Introduction</title> -<subsection> -<title>SELinux Concepts</title> -<body> - -<p> -Since SELinux is a MAC system, you should already figure out that managing -SELinux-based permissions and rights might be a bit more challenging than -managing the discretionary access control rights generally used on a Linux -system. What is more is that SELinux works <b>on top of</b> the DAC system -everybody is used from Linux. As a system administrator, you will need to be -acquainted with some of the concepts and structures that SELinux has put in -place in order to manage the access on the SELinux system. -</p> - -<p> -Describing those concepts is the purpose of this particular chapter. We will -give examples on the various concepts from a SELinux enabled Gentoo Hardened -system. However, do not fear if the use of particular commands is not explained -sufficiently. They are currently meant as examples (their output is more -important) and will be discussed further in this document. -</p> - -</body> -</subsection> -<subsection> -<title>SELinux Policies</title> -<body> - -<p> -Within Gentoo (and other distributions as well), SELinux is supported through -several policy levels. These are, in climbing order of complexity (meaning they -can offer more security, but are harder to manage): -</p> - -<ol> - <li> - <b>targeted</b> is a policy where network-facing services (daemons) are - confined (the processes can only execute those actions that are defined - in the policy), but other applications are running what is called - <e>unconfined</e>, meaning that there are little to no restrictions for - those processes. - </li> - <li> - <b>strict</b> is a policy where all processes are confined. There are no - unconfined domains. In other distributions, this is still considered the - <e>targeted</e> policy but without the unconfined domain definition. - </li> - <li> - <b>multi-category security</b> is a policy where the (confined) domains can - be categorized (split up), allowing for multiple processes running in - different instances of a confined domain - </li> - <li> - <b>multi-level security</b> is a policy where rules exist regarding the - sensitivity of domains and resources. This allows for a "proper" - information flow policy (make sure that sensitive data isn't leaked - to less privileged domains). Conceptually, one can understand this best - if one considers sensitivity levels of Public, Internal, Confidential, - Strictly Confidential, etc. - </li> -</ol> - -<p> -When using Gentoo Hardened, all these policies are available. However, -development focuses mainly on <e>strict</e> and <e>mcs</e>. The -<e>targeted</e> policy is assumed to work if strict works whereas we know -that the <e>mls</e> policy is currently not fit yet for production use. -</p> - -<note> -To clear up some confusion, especially when trying to seek support outside -Gentoo: our "strict" implementation is not what was "strict" up to the year -2008. The old meaning of strict involved a different implementation of the -policy. -</note> - -</body> -</subsection> -</section> -<section> -<title>Security Contexts</title> -<subsection> -<title>Users, Roles, Domains, Sensitivities and Categories</title> -<body> - -<p> -One of the first concepts you will need to be acquainted with is the concept of -a <e>security context</e>. This is a state given to a resource that uniquely -identifies which grants (permissions) are applicable to the resource. This -context is extremely important for SELinux as it is the definition on which it -bases its permissions (grants or denials). When a resource has no security -context assigned, SELinux will try to give it a default security context which - -in the spirit of lowest privilege - has little permissions to perform any actions. -</p> - -<p> -Within SELinux, such a security context is displayed using three to five -definitions, depending on the type of policy you are running: -</p> - -<dl> - <dt>user</dt> - <dd> - This is the <e>SELinux user</e> (which is not the same as the Linux/Unix - technical user) assigned to the resource - </dd> - <dt>role</dt> - <dd> - This is the SELinux role in which the resource currently works - </dd> - <dt>type</dt> - <dd> - This is the type assigned to the resource and is the key to SELinux' - enforcement rules - </dd> - <dt>sensitivity</dt> - <dd> - This is a level given to a resource informing the system about the - sensitivity of this resource. A sensitivity is something akin to - Public, Internal, Restricted, Confidential, Strictly Confidential, ... - Sensitivity levels are only supported in MLS policies. - </dd> - <dt>category</dt> - <dd> - This is a specific instantiation of a resource. It allows segregation of - resources even if they are of the same type. More about categories later - - categories are supported in MLS and MCS policies. - </dd> -</dl> - -<p> -More information on these particular definitions is given throughout the -remainder of this chapter. -</p> - - -<p> -As an example let's take a look at the security context of a logged on user: -</p> - -<pre caption="Getting the security context of a logged on user"> -~$ <i>id -Z</i> -staff_u:staff_r:staff_t -</pre> - -<p> -In this case, the user is identified as the SELinux user <e>staff_u</e>, -currently in the <e>staff_r</e> role and assigned to the <e>staff_t</e> -type. The actions the user is allowed to do are based upon this security -context. Also, you notice that only three identifiers are shown. This is -because the example is taken on a <e>strict</e> (or <e>targeted</e>) policy -system. The next example gives the same result, but on an <e>MCS</e> policy -system. -</p> - -<pre caption="Getting the security context of a logged on user on an MCS policy system"> -~$ <i>id -Z</i> -staff_u:staff_r:staff_t:s0-s0:c0.c1023 -</pre> - -<p> -Here, the user is running with sensitivity level of s0 (which, in an MCS policy -system, is the only available sensitivity) and with a category set of c0 up to -and including c1023. However, note that in an MCS policy system categories are -optional, so you might just see an output of <e>staff_u:staff_r:staff_t:s0</e>. -</p> - -</body> -</subsection> -<subsection> -<title>Access Control Policy</title> -<body> - -<p> -As mentioned before, these security contexts are used as the base for the -permission rules. What SELinux does is check the security context of the source -(for instance a process) and the destination (for instance a file that that -process wants to read). It then checks if the requested operation (read) is -allowed between those two contexts. Keep in mind though that SELinux works on -top of the standard permission system used by Linux. If a process is not able to -read a file to begin with, SELinux is not even consulted. -</p> - -<p> -Now, where the security context defines the state of a resource, we have not -spoken about the resources themselves. Within SELinux, the resource types are -defined as <e>object classes</e>. Common examples are <e>file</e> or <e>dir</e>, -but SELinux also manages classes such as <e>filesystem</e>, <e>tcp_socket</e>, -<e>process</e>, <e>sem</e> (semaphores) and more. -</p> - -<p> -On each object class, a set of <e>permissions</e> is declared which are possible -against a resource within this object class. For instance, the <e>process</e> -object class supports at least the following permissions: -</p> - -<pre caption="Supported permissions against a 'process' resource"> -~# <i>ls /selinux/class/process/perms</i> -dyntransition getcap rlimitinh setpgid siginh -execheap getpgid setcap setrlimit sigkill -execmem getsched setcurrent setsched signal -execstack getsession setexec setsockcreate signull -fork noatsecure setfscreate share sigstop -getattr ptrace setkeycreate sigchld transition -</pre> - -<p> -The most common SELinux access control rule (<e>allow</e>) is described as -follows: -</p> - -<pre caption="SELinux allow statement"> -allow ACTOR TARGET:CLASS PRIVILEGE; - +-+-+ +-+--+ +-+-+ +---+---+ - | | | `- Permission to be granted (like "write") - | | `- Class on which permission is given (like "file") - | `- Resource (label) on which permission is valid (like "portage_conf_t") - `- Actor (domain) which gets the privilege (like "sysadm_t") -</pre> - -<p> -Let's take a look at a small example to explain the permission rules and how -SELinux uses them. The example user is in the <e>staff_u:staff_r:staff_t</e> -context and wants to write to its own home directory. As we can expect, this -should be allowed. Don't worry about the commands here, we'll discuss them more -properly further in this document. -</p> - -<pre caption="Seeing if a user can write to its own home directory"> -<comment>(Show the security context for the users' home directory)</comment> -~$ <i>ls -dZ ${HOME}</i> -staff_u:object_r:user_home_dir_t /home/swift - -<comment>(Find the allow-rule which allows the staff_t type to write into a - directory with the user_home_dir_t type)</comment> -~$ <i>sesearch -s staff_t -t user_home_dir_t -c dir -p write -A</i> -Found 1 semantic av rules: - allow staff_t user_home_dir_t : dir { ioctl read write create ... }; -</pre> - -<p> -As expected, the security context of the user (to be more specific, the domain -in which it resides) has write access to the domain of the target's directories. -The notion of <e>domain</e> is frequently used in SELinux documentation and -refers to the type assigned to a process. BTW, as files do not have roles, -they are given the default <e>object_r</e> role by SELinux. -</p> - -<p> -Now take a look at the following example. Our user, who is inside the portage -group, wants to write to the <path>/var/tmp/portage</path> directory: -</p> - -<pre caption="Seeing if a user can write to the /var/tmp/portage directory"> -~$ <i>id -a</i> -uid=1001(swift) gid=100(users) groups=100(users),...,250(portage),... -~$ <i>ls -ldZ /var/tmp/portage</i> -drwxrwxr-x. 3 portage portage system_u:object_r:portage_tmp_t 4096 Dec 6 21:08 /var/tmp/portage -</pre> - -<p> -From the standard Linux permissions, the user has write access. But does SELinux -also grant it? -</p> - -<pre caption="Trying to write into /var/tmp/portage"> -~$ <i>sesearch -s staff_t -t portage_tmp_t -c dir -p write -A</i> -~$ -<comment>(Notice that there is no output given here)</comment> -~$ <i>touch /var/tmp/portage/foo</i> -touch: cannot touch '/var/tmp/portage/foo': Permission denied -</pre> - -<p> -As SELinux could not find a rule that allows the staff_t domain to write to any -directory labeled with the portage_tmp_t type, the permission was denied. -</p> - -</body> -</subsection> -</section> -<section> -<title>Type Enforcements / Domain Types</title> -<subsection> -<title>Types and Domains</title> -<body> - -<p> -To explain how the permission rules work and how this is enforced through the -security contexts, let's start from the last definition in the context (the -<e>type</e>) and work our way forward through the roles and users. -</p> - -<ul> - <li> - A <e>SELinux type</e> is a particular label assigned to a resource. The - <c>passwd</c> command for instance is labeled with the passwd_exec_t type. - </li> - <li> - A <e>SELinux domain</e> is the security state of a process and identifies the rights - and permissions it has. It is most often referred to by its type declaration. - For instance, for a running <c>passwd</c> command, its domain is passwd_t. - </li> -</ul> - -<p> -The rules that identify the allowed actions for a domain have been described earlier. Again: -</p> - -<pre caption="Standard SELinux policy rules"> -allow <src_domain> <dst_type> : <class> { permission [ permission [ ... ] ] } ; -</pre> - -<p> -An example for the <e>passwd_t</e> domain would be the permissions granted -between the <e>passwd_t</e> domain and the <e>shadow_t</e> type (used by the -<path>/etc/shadow</path> file). -</p> - -<pre caption="Grants between passwd_t and shadow_t"> -allow passwd_t shadow_t : file { ioctl read write create ... } ; -</pre> - -<p> -This permission syntax is very powerful, but also difficult. To have a secure -system where normal behavior is allowed, you need to seriously fine-tune these -rules for each and every application (and thus domain) that your system wants to -host. Giving too broad permissions to a domain on a particular type might result -in unauthorized activity being granted. Giving too few permissions might result -in loss of efficiency or even effectiveness. -</p> - -<p> -To support easier grant rules, SELinux allows grouping of types using type -attributes. For instance, the attribute <e>exec_type</e> bundles all types -that are assigned to executable files (such as <e>bin_t</e>, <e>ssh_exec_t</e>, -...), whereas the <e>file_type</e> attribute bundles all types that are -assigned to regular files. Although this can simplify rule management, it makes -it easier to grant too many permissions. -</p> - -</body> -</subsection> -<subsection> -<title>Domain Transitions</title> -<body> - -<p> -So far for types, domain definitions and their permissions. We have stated before -that permissions are based on the domain in which a process resides. But how -does a process become part of the domain? You might think that this happens by -default (starting the <c>passwd</c> command would automatically bring the -process in the <e>passwd_t</e> domain), but this is in fact a combination of -three specific privileges that need to be granted: -</p> - -<ol> - <li> - The current domain must be allowed to transition to a domain - </li> - <li> - The target domain should have an <e>entry point</e>, which is an executable - that is allowed to start in the domain - </li> - <li> - The source domain should have <e>execute</e> rights on (the domain of) that - executable - </li> -</ol> - -<impo> -Not being allowed to transition does not mean that you cannot -execute the binary. The binary can still be executed, but will not run inside -the target domain. Instead, it will inherit the domain of the executor and hence -the rights and permissions of this domain. -</impo> - -<p> -Through these rules, the security administrator of a system can more -specifically control who and under which conditions particular actions can be -taken. -</p> - -</body> -</subsection> -</section> -<section> -<title>Roles and Rights</title> -<subsection> -<title>The Role of a Role</title> -<body> - -<p> -The previously discussed domains and domain rules is quite powerful. However, -this is not where SELinux stops. After all, you want to be able to deny access -towards particular domains from unauthorized users. One requirement is of course -not to allow transitions from the user domain to that restricted domain, but how -can you enforce one set of users to be allowed and another to be denied? -</p> - -<p> -Enter the roles. By using roles, you can tell SELinux which domains are allowed -for a role and which aren't. An example would be the <e>ifconfig_t</e> domain. -This domain has the rights to change the networking interface definitions - not -something you want to allow your users. And in fact, if you would verify, -SELinux does not allow the user role <e>user_r</e> to be assigned with the -<e>ifconfig_t</e> domain. -</p> - -<pre caption="ifconfig_t domain and user_r versus sysadm_r"> -~$ <i>seinfo -ruser_r -x</i> - user_r - Dominated Roles: - user_r - Types: - ... -~$ <i>seinfo -rsysadm_r -x</i> - sysadm_r - Dominated Roles: - sysadm_r - Types: - ... - ifconfig_t - ... -</pre> - -<impo> -Again, not being able to be associated with a domain does not mean that the -<e>user_r</e> role cannot <e>execute</e> the <c>ifconfig</c> binary. It can, but -it will execute the binary within its own domain (<e>user_t</e>) and as such -will not have the rights to manipulate the networking interface (but will still -be able to read the interface information albeit with limited output). -</impo> - -<p> -Roles are often used in access control systems to group permissions to a single -functional set (the role) which can then be assigned to individuals (accounts). -For instance, such access control systems create roles for accountants, -operators, managers, ... and grant the appropriate privileges to these roles. -Then, their users are assigned one (or sometimes multiple) roles and the users -inherit the permissions assigned to these roles. -</p> - -<p> -With SELinux, the idea remains the same (use roles to functionally differentiate -privileges) but is implemented differently: roles are assigned target domains -in which a role is allowed to "be in". The permissions remain assigned to the -domains. -</p> - -</body> -</subsection> -<subsection> -<title>Role Transitions</title> -<body> - -<p> -Users (and processes) have the ability to switch roles. This is allowed by -SELinux, but of course only when the switch itself is granted. By default, -the SELinux policy used by Gentoo Hardened offers five roles on a SELinux -system: -</p> - -<dl> - <dt>object_r</dt> - <dd> - The <e>object_r</e> role is the only role by default available through - SELinux. It is usually only assigned to resources where roles have no - benefit or value (such as files and directories). - </dd> - <dt>system_r</dt> - <dd> - The <e>system_r</e> role is used for highly privileged system services. - The <e>system_r</e> role is allowed to switch to any other "default" role. - No role exception <e>sysadm_r</e> can switch to the <e>system_r</e> role. - </dd> - <dt>sysadm_r</dt> - <dd> - The <e>sysadm_r</e> role is used for system administration activities. The - <e>sysadm_r</e> role is allowed to switch to any other "default" role. Only - the <e>system_r</e> and <e>staff_r</e> roles are allowed to switch to the - <e>sysadm_r</e> role. - </dd> - <dt>staff_r</dt> - <dd> - The <e>staff_r</e> role is used for system operators who might have the - rights to perform system administration tasks. The <e>staff_r</e> role is - only allowed to switch to the <e>sysadm_r</e> role. Only <e>sysadm_r</e> and - <e>system_r</e> can switch to the <e>staff_r</e> role. - </dd> - <dt>user_r</dt> - <dd> - The <e>user_r</e> role is used for standard, unprivileged users. It is not - allowed to transition towards any other role; only <e>sysadm_r</e> and - <e>system_r</e> roles are allowed to switch to the <e>user_r</e> role. - </dd> -</dl> - -<note> -A "default" role is any of <e>user_r</e>, <e>staff_r</e>, <e>sysadm_r</e> or -<e>system_r</e>. If you create additional roles yourself, they are not part of -the "default" roles. -</note> - -<p> -Using these definitions, a user inside the <e>user_r</e> role will never be able -to execute <c>ifconfig</c> within the <e>ifconfig_t</e> domain. The use of the -word <e>never</e> here is important: not even if the user is able to become -root using <c>sudo</c> or any other command will he be able to run the -<c>ifconfig</c> command in the <e>ifconfig_t</e> domain because, even after -running <c>sudo</c>, he is still inside the <e>user_r</e> role. -</p> - -</body> -</subsection> -<subsection> -<title>SELinux Users</title> -<body> - -<p> -A SELinux user is not the same as the Linux user. Whereas standard Linux user -accounts can be switched using commands such as <c>su</c> or <c>sudo</c>, a -SELinux user can not be changed. Even when you successfully execute <c>sudo</c>, -your SELinux user will remain the same. -</p> - -<p> -When you look at a SELinux powered system, you might notice that that system -doesn't use many SELinux users. For instance, Gentoo Hardened's default setup -defines the users <e>root</e>, <e>user_u</e>, <e>staff_u</e>, <e>sysadm_u</e> and -<e>system_u</e> and some systems never introduce any other SELinux user. But if -that is the case, is the above advantage of SELinux users (once a user is logged -on, he cannot change his SELinux user) the only one? -</p> - -<p> -Well, no. SELinux users are also used to categorize accounts which have the -permission to use a particular role. -</p> - -<pre caption="SELinux users and their associated roles"> -~# <i>semanage user -l</i> -SELinux User SELinux Roles - -root staff_r sysadm_r -staff_u staff_r sysadm_r -sysadm_u sysadm_r -system_u system_r -user_u user_r -</pre> - -<p> -Standard Linux users are mapped to these SELinux users: -</p> - -<pre caption="Linux users and their SELinux user mappings"> -~# <i>semanage login -l</i> -Login Name SELinux User - -__default__ user_u -root root -swift staff_u -</pre> - -<p> -In this example, only logins of the Linux user <e>swift</e> (through -<e>staff_u</e>) and <e>root</e> (through the <e>root</e> SELinux user) -will be able to eventually run inside the <e>sysadm_r</e> role. All other -Linux accounts will be by default mapped to the <e>user_u</e> user (and -this <e>user_r</e> role). -</p> - -<p> -This is <e>only</e> applicable for interactive logins. Processes that are -launched through an init script or otherwise do not automatically become part of -the SELinux user <e>user_u</e>: depending on the security context of whatever -process is starting them, they can become anything. Of course, if the security -context of the process that is starting them is <e>user_u:user_r:user_t</e> then -they will not be able to transform into anything other than -<e>user_u:user_r:*</e> with <e>*</e> a domain supported by the <e>user_r</e> -role. -</p> - -<p> -SELinux users are also used to implement <e>User Based Access Control</e> or -<e>UBAC</e>. This SELinux functionality allows for domains to be SELinux user -aware: a process running in the context of a particular SELinux user can then - -for instance - only work with files of the same SELinux user. This offers a -finer grained access method, because that process might run within a domain -which has write access to the domain of the file, but can still not write to the -file because the SELinux users' differ. -</p> - -<p> -At this moment, Gentoo Hardened SELinux' supports both policies with and -without UBAC, although we strongly recommend to use UBAC. This is controlled -through the <c>ubac</c> USE flag. -</p> - -</body> -</subsection> -</section> -<section> -<title>Multi Level Security / Multi Category Security</title> -<subsection> -<title>Introduction</title> -<body> - -<p> -Next to the type enforcement feature, SELinux also offers MLS and MCS support. -This allows administrators to define a hierarchical confidentiality policy. -For instance, you can ensure that a user or process within a certain -security domain and level can write to files with the same level (or higher), or -read files with the same level (or lower), but not write files to a lower level. -This allows administrators to implement some sort of -public/internal/confidential/strictly confidential hierarchical security level -for files. -</p> - -<p> -Although implementation of MLS is possible with the type enforcement rules we -have previously explained, it would lead to an unmanageable collection of types -and permissions. The MLS implementation simplifies this. -</p> - -</body> -</subsection> -<subsection> -<title>Multi-Level Security</title> -<body> - -<p> -The most flexible - but also most challenging to manage - method offered by -SELinux is MLS, or <e>Multi-Level Security</e>. When using this policy type, -security administrators can assign sensitivity labels to resources and define -which domains (and which sensitivity levels) are able to read/write to which -level. A level is always given as a range, showing the lowest and highest level -that a particular domain is running in. -</p> - -<p> -Next to the sensitivity level, MLS supports categories on a per-level basis. -These categories allow the security administrator to make different, possibly -independent "containers" for sensitive resources. To give an example, the -administrator can support the levels Public up to Strictly Confidential, and -categories of "Finance", "Risk Analysis", "Acquisitions", "IT Systems", ... -</p> - -<p> -With such categories, one can then allow one role to have access to all -sensitivity levels for a particular category (say "IT Systems") but still only -have access to the Public and Internal documents of all other categories. -</p> - -</body> -</subsection> -<subsection> -<title>Multi-Category Security</title> -<body> - -<p> -The MCS or <e>Multi-Category Security</e> policy is a subset of the MLS policy. -It supports the various categories, but without using the multiple security -levels for the resources. -</p> - -<p> -The use of MCS has become popular because it is far less difficult to manage -while still retaining some of the flexibilities offered by the MLS policy. -Where MLS is more chosen for business purposes (and as such has some influence -on the organization of the business), MCS is often used for <e>multitenancy</e> -architectures. In a multi-tenant architecture, systems are running processes for -various clients simultaneously. Categorisation allows for separation of -privileges across these processes without introducing multiple domains (which -would require the development of new policies for each new client that a system -wants to serve). -</p> - -</body> -</subsection> -</section> - -<section> -<title>Reference Policy</title> -<subsection> -<title>About refpolicy</title> -<body> - -<p> -As described previously, SELinux uses type enforcement to describe the state of -your system. This is done by giving each resource on your system (be it a -process, a network port, a file or directory) a specific type and describe the -rules how types can work with each other. -</p> - -<p> -Managing such a policy is not easy. Unlike some other MAC systems, which rely -on a learning mode and do not use domain definitions (they rather keep track of -which commands a process is allowed to execute), a proper SELinux definition -requires lots (thousands and thousands) of permission lines. -</p> - -<p> -To ensure that no duplicate effort is made, and to help distributions like -Gentoo, Fedora, RedHat, Debian, ... with their SELinux integration efforts, a -project is launched called <e>The Reference Policy</e>. -</p> - -<p> -This project, managed by <uri -link="http://oss.tresys.com/projects/refpolicy">Tresys</uri>, is used by almost -all SELinux supporting distributions, including Gentoo Hardened, Fedora, RedHat -Enterprise Linux, Debian, Ubuntu and more. This implementation not only offers -the modular policies that users are looking for, but also enhances the SELinux -experience with additional development tools that make it easier to work with -the SELinux policies on your system. Updates in the reference policy eventually -make it in all supported distributions. The same goes for Gentoo Hardened, which -aims to use a policy as close as possible to the reference policy, and submits -its own patches to the reference policy as well, which benefits the entire -community. -</p> - -</body> -</subsection> -<subsection> -<title>Reference Policy API</title> -<body> - -<p> -One major advantage of the reference policy is its API. To help policy writers, -the reference policy uses a macro language which generates the necessary allow -(and other) rules. This macro language makes it a lot easier to add rights to -particular domains. You can find the API documented <uri -link="http://oss.tresys.com/docs/refpolicy/api/">online</uri>, but if you have -USE="doc" set, it will be stored on your system as well the moment you install -and configure SELinux. -</p> - -</body> -</subsection> -<subsection> -<title>Modular Approach</title> -<body> - -<p> -Another feature of the reference policy is its use of <e>modules</e>. If you -would build all rules in a single policy (a binary file readable by the Linux -kernel, allowing it to interpret and enforce SELinux rules), the file would -quickly become too huge and inefficient. -</p> - -<p> -Instead, the reference policy defines the rules in what it calls modules, which -define one domain (like <c>portage_t</c>) or more (if they are all tightly -related) and the rights and privileges that that domain would need in order to -function properly. Any right that the domain needs with respect to another -domain needs to be defined through that domains' interfaces (see earlier), -forcing the modules to be specific and manageable. -</p> - -<pre caption="Example overview of installed SELinux modules"> -# <i>semodule -l</i> -alsa 1.11.0 -apache 2.3.0 -audioentropy 1.6.0 -dbus 1.15.0 -dmidecode 1.4.0 -<comment>(...)</comment> -</pre> - -<p> -By using a modular approach, one only needs to load the base policy (kernel -layer as well as other, core definitions) and the modules related to his system. -You can then safely ignore the other modules. This improves performance (smaller -policy, which also causes rebuilds to be a lot less painful) and manageability -(properly defined boundaries for policy rules). -</p> - -</body> -</subsection> -<subsection> -<title>Tunables and Conditionals</title> -<body> - -<p> -But wait, there's more. The reference policy also supports <e>booleans</e>. -Those are flags that a security administrator can enable or disable to change -the active policy. Properly defined booleans allow security administrators to -fine-tune the policy for their system. -</p> - -<pre caption="Overview of available booleans"> -# <i>getsebool -a</i> -allow_execheap --> off -allow_execmem --> off -allow_execmod --> off -allow_execstack --> off -allow_gssd_read_tmp --> on -allow_httpd_anon_write --> off -</pre> - -<p> -Booleans are an important part to make a generic reference policy which is still -usable for the majority of SELinux users. Although they have specific -requirements (such as allowing ptrace, or disallowing execmem) they can still -use the same reference policy and only need to toggle the booleans they need. -</p> - -</body> -</subsection> -<subsection> -<title>Policy Files and Versions</title> -<body> - -<p> -The SELinux policy infrastructure that is used (i.e. the capabilities and -functionalities that it offers) isn't in its first version. Currently, SELinux -deployments use a binary version of 24 or 26 (depending on the kernel version -used). -</p> - -<pre caption="Getting the binary policy version"> -# <i>sestatus</i> -SELinux status: enabled -SELinuxfs mount: /selinux -Current mode: enforcing -Mode from config file: enforcing -Policy version: 24 -Policy from config file: strict -</pre> - -<p> -Every time functionalities or capabilities are added which require -changes to the internal structure of the compiled policy, this version is -incremented. The following is an overview of the policy versions' history. -</p> - -<dl> - <dt>Version 12</dt> - <dd>"Old API" for SELinux, which is now deprecated</dd> - <dt>Version 15</dt> - <dd>"New API" for SELinux, merged in Linux kernel 2.6.0 (until 2.6.5)</dd> - <dt>Version 16</dt> - <dd>Conditional policy extensions added (2.6.5)</dd> - <dt>Version 17</dt> - <dd>IPV6 support added (2.6.6 - 2.6.7)</dd> - <dt>Version 18</dt> - <dd>Fine-grained netlink socket support added (2.6.8 - 2.6.11)</dd> - <dt>Version 19</dt> - <dd>Enhanced multi-level security (2.6.12 - 2.6.13)</dd> - <dt>Version 20</dt> - <dd>Access vector table size optimizations (2.6.14 - 2.6.18)</dd> - <dt>Version 21</dt> - <dd>Object classes in range transitions (2.6.19 - 2.6.24)</dd> - <dt>Version 22</dt> - <dd>Policy capabilities (features) (2.6.25)</dd> - <dt>Version 23</dt> - <dd>Per-domain permissive mode (2.6.26 - 2.6.27)</dd> - <dt>Version 24</dt> - <dd>Explicit hierarchy (type bounds) (2.6.28 - 2.6.38)</dd> - <dt>Version 25</dt> - <dd>Filename based transition support (2.6.39)</dd> - <dt>Version 26</dt> - <dd>Role transition support for non-process classes (3.0)</dd> -</dl> - - -</body> -</subsection> -</section> - -<section> -<title>Next Steps</title> -<subsection> -<title>What Next</title> -<body> - -<p> -It might be difficult to understand now, but the concepts are important because, -if something fails on your system when SELinux is enabled, but it doesn't fail -when SELinux is disabled, then you will need to dive into the security contexts, -rules, types and domain transitions to find out why. -</p> - -<p> -The next chapter in line will give you some background resource information -(online resources, books, FAQs, etc.) After that, we'll dive into the -installation and configuration of SELinux on your Gentoo Hardened system. Then, -we'll configure and tune the SELinux policy to our needs. -</p> - -</body> -</subsection> -</section> -</sections> |