diff options
| author |   Sven Vermeulen <sven.vermeulen@siphos.be> | 2012-05-26 17:54:46 +0200 |
|---|---|---|
| committer | Sven Vermeulen <sven.vermeulen@siphos.be> | 2012-05-26 17:54:46 +0200 |
| commit | 1439140807dfa46775a8b6fb1de0749ce665cb62 (patch) | |
| tree | 75f56ae74997217a4711de5734336e42578aa9ef | |
| parent | Update on localpolicy (diff) | |
| download | hardened-docs-1439140807dfa46775a8b6fb1de0749ce665cb62.tar.gz hardened-docs-1439140807dfa46775a8b6fb1de0749ce665cb62.tar.bz2 hardened-docs-1439140807dfa46775a8b6fb1de0749ce665cb62.zip | |
Removing selinux stuff from overlay - main docs are in CVS, no major updates needed for the time coming. If needed, just copy back. therwise its dual work.
| -rw-r--r-- | xml/selinux-faq.xml | 952 | ||||
| -rw-r--r-- | xml/selinux/hb-intro-concepts.xml | 910 | ||||
| -rw-r--r-- | xml/selinux/hb-intro-enhancingsecurity.xml | 387 | ||||
| -rw-r--r-- | xml/selinux/hb-intro-referencepolicy.xml | 255 | ||||
| -rw-r--r-- | xml/selinux/hb-intro-resources.xml | 111 | ||||
| -rw-r--r-- | xml/selinux/hb-intro-virtualization.xml | 25 | ||||
| -rw-r--r-- | xml/selinux/hb-using-commands.xml | 492 | ||||
| -rw-r--r-- | xml/selinux/hb-using-configuring.xml | 981 | ||||
| -rw-r--r-- | xml/selinux/hb-using-install.xml | 741 | ||||
| -rw-r--r-- | xml/selinux/hb-using-policies.xml | 520 | ||||
| -rw-r--r-- | xml/selinux/hb-using-states.xml | 367 | ||||
| -rw-r--r-- | xml/selinux/hb-using-troubleshoot.xml | 349 | ||||
| -rw-r--r-- | xml/selinux/index.xml | 156 | ||||
| -rw-r--r-- | xml/selinux/selinux-handbook.xml | 199 |
14 files changed, 0 insertions, 6445 deletions
diff --git a/xml/selinux-faq.xml b/xml/selinux-faq.xml deleted file mode 100644 index 5fe99fe..0000000 --- a/xml/selinux-faq.xml +++ /dev/null @@ -1,952 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> -<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux-faq.xml,v 1.2 2011/04/25 20:21:47 zorry Exp $ --> - -<guide> -<title>Gentoo Hardened SELinux Frequently Asked Questions</title> -<author title="Author"> - <mail link="pebenito@gentoo.org">Chris PeBenito</mail> -</author> -<author title="Author"> - <mail link="sven.vermeulen@siphos.be">Sven Vermeulen</mail> -</author> - -<abstract> -Frequently Asked Questions on SELinux integration with Gentoo Hardened. -The FAQ is a collection of solutions found on IRC, mailinglist, forums or -elsewhere -</abstract> - -<version>23</version> -<date>2012-05-21</date> - -<faqindex> -<title>Questions</title> -<section> -<title>Introduction</title> -<body> - -<p> -Using SELinux requires administrators a more thorough knowledge of their -system and a good idea on how processes should behave. Next to the <uri -link="/proj/en/hardened/selinux/selinux-handbook.xml">Gentoo Hardened SELinux -handbook</uri>, a proper FAQ allows us to inform and help users in their -day-to-day SELinux experience. -</p> - -<p> -The FAQ is an aggregation of solutions found on IRC, mailinglists, forums -and elsewhere. It focuses on SELinux integration on Gentoo Hardened, but -general SELinux questions that are popping up regularly will be incorporated -as well. -</p> - -</body> -</section> -</faqindex> - -<chapter> -<title>General SELinux Support Questions</title> -<section id="features"> -<title>Does SELinux enforce resource limits?</title> -<body> - -<p> -No, resource limits are outside the scope of an access control system. If you -are looking for this type of support, take a look at technologies like -grsecurity, cgroups, pam and the like. -</p> - -</body> -</section> -<section id="grsecurity"> -<title>Can I use SELinux with grsecurity (and PaX)?</title> -<body> - -<p> -Definitely, we even recommend it. However, it is suggested that grsecurity's -ACL support is not used as it would be redundant to SELinux's access control. -</p> - -</body> -</section> -<section id="pie-ssp"> -<title>Can I use SELinux and the hardened compiler (with PIE-SSP)?</title> -<body> - -<p> -Definitely. We also suggest to use PaX to take full advantage of the PIE -features of the compiler. -</p> - -</body> -</section> -<section id="rsbac"> -<title>Can I use SELinux and RSBAC?</title> -<body> - -<p> -Yes, SELinux and RSBAC can be used together, but it is not recommended. -Both frameworks (RSBAC and the SELinux implementation on top of Linux' Linux -Security Modules framework) have a slight impact on system performance. -Enabling them both only hinders performance more, for little added value since -they both offer similar functionality. -</p> - -<p> -In most cases, it makes more sense to use RSBAC without SELinux, or SELinux -without RSBAC. -</p> - -<!-- -If users are unclear, mention that you can compile both in and then try to -only enable one (configuration wise), but that this has little benefit on -the performance (since the hooks are there, the checks that are made are just -a bit different but due to caching, the overhead of having it enabled versus -disabled is small anyhow). ---> - -</body> -</section> -<section id="filesystem"> -<title>Can I use SELinux with any file system?</title> -<body> - -<p> -SELinux requires access to a file's security context to operate properly. -To do so, SELinux uses <e>extended file attributes</e> which needs to be -properly supported by the underlying file system. If the file system supports -extended file attributes and you have configured your kernel to enable this -support, then SELinux will work on those file systems. -</p> - -<p> -General Linux file systems, such as ext2, ext3, ext4, jfs, xfs and btrfs -support extended attributes (but don't forget to enable it in the kernel -configuration) as well as tmpfs (for instance used by udev). If your file -system collection is limited to this set, then you should have no issues. -</p> - -<p> -Ancillary file systems such as vfat and iso9660 are supported too, but with -an important caveat: all files in each file system will have the same SELinux -security context information since these file systems do not support extended -file attributes. -</p> - -<p> -Network file systems can be supported in the same manner as ancillary file -systems (all files share the same security context). However, some development -has been made in supported extended file attributes on the more popular file -systems such as NFS. Although this is far from production-ready, it does look -like we will eventually support these file systems on SELinux fully as well. -</p> - -</body> -</section> -<section id="nomultilib"> -<title>Can I use SELinux with AMD64 no-multilib?</title> -<body> - -<!-- FAQ might be removed in the future since it is now obvious --> - -<p> -Yes, just use the <path>hardened/linux/amd64/no-multilib/selinux</path> profile -and you're all set. -</p> - -</body> -</section> -<section id="ubac"> -<title>What is UBAC exactly?</title> -<body> - -<p> -UBAC, or <e>User Based Access Control</e>, introduces additional constraints -when using SELinux policy. Participating domains / types that are <e>both</e> -marked as a <c>ubac_constrained_type</c> (which is an attribute) will only -have the allowed privileges in effect if they both run with the same SELinux -user context. -</p> - -<pre caption="Domains and their SELinux user context"> -<comment># The SELinux allow rule</comment> -allow foo_t bar_t:file { read }; - -<comment># This will succeed:</comment> -staff_u:staff_r:foo_t reads file with type staff_u:object_r:bar_t - -<comment># This will be prohibited:</comment> -user_u:user_r:foo_t reads file with type staff_u:object_r:bar_t -</pre> - -<p> -Of course, this is not always the case. Besides the earlier mentioned -requirement that both types are <c>ubac_constrained_type</c>, if the source -domain is <c>sysadm_t</c>, then the constraint will not be in effect (the -<c>sysadm_t</c> domain is exempt from UBAC constraints). Also, if the source -or destination SELinux user is <c>system_u</c> then the constraint will also -not be in effect. -</p> - -</body> -</section> -</chapter> - -<chapter> -<title>Using SELinux</title> -<section id="enable_selinux"> -<title>How do I enable SELinux?</title> -<body> - -<p> -This is explained in the <uri -link="/proj/en/hardened/selinux/selinux-handbook.xml">SELinux Handbook</uri> -in the chapter on <e>Using Gentoo/Hardened SELinux</e>. -</p> - -</body> -</section> -<section id="switch_status"> -<title>How do I switch between permissive and enforcing?</title> -<body> - -<p> -The easiest way is to use the <c>setenforce</c> command. With <c>setenforce -0</c> you tell SELinux to run in permissive mode. Similarly, with -<c>setenforce 1</c> you tell SELinux to run in enforcing mode. -</p> - -<p> -You can also add a kernel option <c>enforcing=0</c> or <c>enforcing=1</c> -in the bootloader configuration (or during the startup routine of the system). -This allows you to run SELinux in permissive or enforcing mode from the start -of the system. -</p> - -<p> -The default state of the system is kept in <path>/etc/selinux/config</path>. -</p> - -</body> -</section> -<section id="disable_selinux"> -<title>How do I disable SELinux completely?</title> -<body> - -<p> -It might be possible that running SELinux in permissive mode is not sufficient -to properly fix any issue you have. To disable SELinux completely, you need to -edit <path>/etc/selinux/config</path> and set <c>SELINUX=disabled</c>. Next, -reboot your system. -</p> - -<impo> -When you have been running your system with SELinux disabled, you must boot -in permissive mode first and relabel your entire file system. Activities ran -while SELinux was disabled might have created new files or removed the labels -from existing files, causing these files to be available without security -context. -</impo> - -</body> -</section> -<section id="matchcontext"> -<title>How do I know which file context rule is used for a particular file?</title> -<body> - -<p> -If you use the <c>matchpathcon</c> command, it will tell you what the security -context for the given path (file or directory) should be, but it doesn't tell -you which rule it used to deduce this. To do that, you can use <c>findcon</c>: -</p> - -<pre caption="Using findcon"> -~# <i>findcon /etc/selinux/strict/contexts/files/file_contexts -p /lib64/rc/init.d</i> -/.* system_u:object_r:default_t -/lib64/rc/init\.d(/.*)? system_u:object_r:initrc_state_t -/lib64/.* system_u:object_r:lib_t -</pre> - -<p> -When the SELinux utilities try to apply a context, they try to match the rule -that is the most specific, so in the above case, it is the one that leads to the -initrc_state_t context. -</p> - -<p> -The most specific means, in order of tests: -</p> - -<ol> - <li> - If line A has a regular expression, and line B doesn't, then line B is more - specific. - </li> - <li> - If the number of characters before the first regular expression in line A is - less than the number of characters before the first regular expression in - line B, then line B is more specific - </li> - <li> - If the number of characters in line A is less than in line B, then line B is - more specific - </li> - <li> - If line A does not map to a specific SELinux type, and line B does, then - line B is more specific - </li> -</ol> - -<p> -However, when you add your own file contexts (using <c>semanage</c>), this does -not apply. Instead, tools like <c>restorecon</c> will take the <e>last</e> hit -within the locally added file contexts! You can check the content of the -locally added rules in <path>/etc/selinux/strict/contexts/files/file_contexts.local</path> -(substitute <path>strict</path> with your SELinux type). -</p> - -</body> -</section> -<section id="localpolicy"> -<title>How do I make small changes (additions) to the policy?</title> -<body> - -<p> -If you are interested in the Gentoo Hardened SELinux development itself, please -have a look at the <uri link="/proj/en/hardened/selinux-development.xml">SELinux -Development Guide</uri> and other documentation linked from the <uri -link="/proj/en/hardened/selinux/index.xml">SELinux project page</uri>. -</p> - -<p> -However, you will eventually need to keep some changes on your policy, due to -how you have configured your system or when you need to allow something that is -not going to be accepted as a distribution-wide policy change. In that case, -read on. -</p> - -<p> -Updates on the policy are only possible as long as you need to <e>allow</e> -additional privileges. It is not possible to remove rules from the policy, only -enhance it. To maintain your own set of additional rules, create a file in which -you will keep your changes. In the next example, I will use the term -<path>fixlocal</path>, substitute with whatever name you like - but keep it -consistent. In the file (<path>fixlocal.te</path>) put in the following text -(again, substitute <path>fixlocal</path> with your chosen name): -</p> - -<pre caption="fixlocal.te content"> -policy_module(fixlocal, 1.0) - -require { -<comment># Declarations of types, classes and permissions used</comment> - -} - -<comment># Declaration of policy rules</comment> -</pre> - -<p> -In this file, you can add rules as you like. In the next example, we add three -rules: -</p> - -<ol> - <li> - Allow <c>mozilla_t</c> the <c>execmem</c> privilege (based on a denial that - occurs when mozilla fails to start) - </li> - <li> - Allow <c>ssh_t</c> to connect to any port rather than just the SSH port - </li> - <li> - Allows the <c>user_t</c> domain to send messages directly to the system - logger - </li> -</ol> - -<pre caption="fixlocal.te content"> -policy_module(fixlocal, 1.0) - -require { - type mozilla_t; - type ssh_t; - type user_t; - - class process { execmem }; -} - -<comment># Grant mozilla the execmem privilege</comment> -allow mozilla_t self:process { execmem }; - -<comment># Allow SSH client to connect to any port (as provided by the user through the -# "ssh -p <portnum> ..." command)</comment> -corenet_tcp_connect_all_ports(ssh_t) - -<comment># Allow the user_t domain to send messages to the system logger</comment> -logging_send_syslog_msg(user_t) -</pre> - -<p> -If you need to provide raw allow statements (like the one above for the -<c>mozilla_t</c> domain), make sure that the type (<c>mozilla_t</c>), -class (<c>process</c>) and privilege (<c>execmem</c>) are mentioned in -the <c>require { ... }</c> paragraph. -</p> - -<p> -When using interface names, make sure that the types (<c>ssh_t</c> and -<c>user_t</c>) are mentioned in the <c>require { ... }</c> paragraph. -</p> - -<p> -To find the proper interface name (like <c>corenet_tcp_connect_all_ports</c> -above), you can either look for it in the <uri -link="http://oss.tresys.com/docs/refpolicy/api/">SELinux Reference Policy -API</uri> online or, if <c>sec-policy/selinux-base-policy</c> is built with the -<e>doc</e> USE flag, in <path>/usr/share/doc/selinux-base-policy-.*/html</path>. -Of course, you can also ask for help in <c>#gentoo-hardened</c> on -irc.freenode.net, the mailinglist, forums, etc. to find the proper rules and -statements for your case. -</p> - -<p> -With the policy file created, you can then build it using the -<path>Makefile</path> provided by the system: -</p> - -<pre caption="Building a fixlocal.pp file"> -<comment>(This uses "strict" as the example policy type, substitute with your -own)</comment> -# <i>make -f /usr/share/selinux/strict/include/Makefile fixlocal.pp</i> -</pre> - -<p> -Then, if the builds succeeds, you can load it in memory. Once loaded, it will be -loaded after every boot as well, so you do not need to repeat this over and over -again. -</p> - -<pre caption="Loading the policy"> -# <i>semodule -i fixlocal.pp</i> -</pre> - -</body> -</section> -</chapter> - -<chapter> -<title>SELinux Kernel Error Messages</title> -<section id="register_security"> -<title>I get a register_security error message when booting</title> -<body> - -<p> -During boot-up, the following message pops up: -</p> - -<pre caption="Kernel message on register_security"> -There is already a security framework initialized, register_security failed. -Failure registering capabilities with the kernel -selinux_register_security: Registering secondary module capability -Capability LSM initialized -</pre> - -<p> -This is nothing to worry about (and perfectly normal). -</p> - -<p> -This means that the Capability LSM module couldn't register as the primary -module, since SELinux is the primary module. The third message means that it -registers with SELinux as a secondary module. -</p> - -</body> -</section> -<section id="permission_not_defined"> -<title>I get a 'Permission ... in class ... not defined' message during booting</title> -<body> - -<p> -During boot-up, the following message is shown: -</p> - -<pre caption="Kernel message on undefined permission(s)"> -SELinux: 2048 avtab hash slots, 16926 rules. -SELinux: 2048 avtab hash slots, 16926 rules. -SELinux: 6 users, 6 roles, 1083 types, 34 bools -SELinux: 77 classes, 16926 rules -SELinux: Permission read_policy in class security not defined in policy. -SELinux: Permission audit_access in class file not defined in policy. -SELinux: Permission audit_access in class dir not defined in policy. -SELinux: Permission execmod in class dir not defined in policy. -... -SELinux: the above unknown classes and permissions will be denied -SELinux: Completing initialization. -</pre> - -<p> -This means that the Linux kernel that you are booting supports permissions that -are not defined in the policy (as offered through the -<c>sec-policy/selinux-base-policy</c> package). If you do not notice any errors -during regular operations, then this can be ignored (the permissions will be -made part of upcoming policy definitions). -</p> - -</body> -</section> -</chapter> -<chapter> -<title>SELinux and Gentoo</title> -<section id="no_module"> -<title>I get a missing SELinux module error when using emerge</title> -<body> - -<p> -When trying to use <c>emerge</c>, the following error message is displayed: -</p> - -<pre caption="Error message from emerge on the SELinux module"> -!!! SELinux module not found. Please verify that it was installed. -</pre> - -<p> -This indicates that the portage SELinux module is missing or damaged. Recent -Portage versions provide this module out-of-the-box, but the security contexts -of the necessary files might be wrong on your system. Try relabelling the files -of the portage package: -</p> - -<pre caption="Relabel all portage files"> -~# <i>rlpkg portage</i> -</pre> - -</body> -</section> -<section id="loadpolicy"> -<title>I get 'FEATURES variable contains unknown value(s): loadpolicy'</title> -<body> - -<p> -When running emerge, the following error is shown: -</p> - -<pre caption="Emerge error on loadpolicy"> -FEATURES variable contains unknown value(s): loadpolicy -</pre> - -<p> -This is a remnant of the older SELinux policy module set where policy packages -might require this FEATURE to be available. This has however since long been -removed from the tree. -</p> - -<p> -Please update your profile to a recent SELinux profile (one ending with -<path>/selinux</path>) and make sure that <path>/etc/make.conf</path> does not -have <c>FEATURES="loadpolicy"</c> set. -</p> - -</body> -</section> -<section id="conflicting_types"> -<title>During rlpkg I get 'conflicting specifications for ... and ..., using ...'</title> -<body> - -<p> -When trying to relabel a package (<c>rlpkg packagename</c>) or system (<c>rlpkg --a -r</c>) you get a message similar to the following: -</p> - -<pre caption="rlpkg complaining about conflicting specifications"> -filespec_add: conflicting specifications for /usr/bin/getconf and -/usr/lib64/misc/glibc/getconf/XBS5_LP64_OFF64, using -system_u:object_r:lib_t -</pre> - -<p> -This is most likely caused by hard linked files. Remember, SELinux uses the -extended attributes in the file system to store the security context of a file. -If two separate paths point to the same file using hard links (i.e. the files -share the same inode) then both files will have the same security context. -</p> - -<p> -The solution depends on the particular case; in order of most likely to happen -and resolve: -</p> - -<ol> - <li> - Although both files are the same, they are not used in the same context. - In such cases, it is recommended to remove one of the files and then copy - the other file back to the first (<c>rm B; cp A B</c>). This way, both - files have different inodes and can be labelled accordingly. - </li> - <li> - Both files are used for the same purpose; in this case, it might be better - to label the file which would not be labelled correctly (say a binary - somewhere in a <path>/usr/lib64</path> location) using <c>semanage</c> - (<c>semanage fcontext -a -t correct_domain_t /usr/lib64/path/to/file</c>) - </li> -</ol> - -<p> -It is also not a bad idea to report (after verifying if it hasn't been reported -first) this on <uri link="https://bugs.gentoo.org">Gentoo's bugzilla</uri> so -that the default policies are updated accordingly. -</p> - -</body> -</section> -<section id="portage_libsandbox"> -<title>During package installation, ld.so complains 'object 'libsandbox.so' -from LD_PRELOAD cannot be preloaded: ignored'</title> -<body> - -<p> -During installation of a package, you might see the following error message: -</p> - -<pre caption="Error message during package installation"> ->> Installing (1 of 1) net-dns/host-991529 ->>> Setting SELinux security labels -ERROR: ld.so: object 'libsandbox.so' from LD_PRELOAD cannot be preloaded: ignored. -</pre> - -<p> -This message should <e>only</e> occur after the <e>Setting SELinux security -labels</e> message. It happens because SELinux tells glibc to disable -<c>LD_PRELOAD</c> (and other environment variables that are considered -potentially harmful) during domain transitions. Here, portage calls the -<c>setfiles</c> command (part of a SELinux installation) and as such -transitions from portage_t to setfiles_t, which clears the environment -variable. -</p> - -<p> -We believe that it is safer to trust the SELinux policy here (as setfiles runs -in its own confined domain anyhow) rather than updating the policy to allow -transitioning between portage_t to setfiles_t without clearing these -environment variables. Note that <e>libsandbox.so is not disabled during builds -and merges</e>, only during the activity where Portage labels the files it -just merged. -</p> - -<p> -So the error is in our opinion cosmetic and can be ignored (but sadly not -hidden). -</p> - -</body> -</section> -<section id="emergefails"> -<title>Emerge does not work, giving 'Permission denied: /etc/make.conf'</title> -<body> - -<p> -This is to be expected if you are not using the <c>sysadm_r</c> role. Any -Portage related activity requires that you are in the <c>sysadm_r</c> role. To -transition to the role, first validate if you are currently known as -<c>staff_u</c> (or, if you added your own SELinux identities, a user that has -the permission to transition to the <c>sysadm_r</c> role). Then run <c>newrole --r sysadm_r</c> to transition. -</p> - -<pre caption="Transitioning to sysadm_r"> -~$ <i>emerge --info</i> -Permission denied: '/etc/make.conf' -~$ <i>id -Z</i> -staff_u:staff_r:staff_t -~$ <i>newrole -r sysadm_r</i> -Password: <comment># Enter your users' password</comment> -</pre> - -<p> -This is also necessary if you logged on to your system as root but through SSH. -The default behavior is that SSH sets the lowest role for the particular user -when logged on. And you shouldn't allow remote root logins anyhow. -</p> - -</body> -</section> -<section id="cronfails"> -<title>Cron fails to load in root's crontab with message '(root) ENTRYPOINT -FAILED (crontabs/root)'</title> -<body> - -<p> -When you hit the mentioned error with a root crontab or an administrative -users' crontab, but not with a regular users' crontab, then check the context of -the crontab file: -</p> - -<pre caption="Check context of the crontab file"> -~# <i>ls -Z /var/spool/cron/crontabs/root</i> -staff_u:object_r:user_cron_spool_t /var/spool/cron/crontabs/root -</pre> - -<p> -Next, check what the default context is for the given user (in this case, root) -when originating from the <c>crond_t</c> domain: -</p> - -<pre caption="Check default context for user root"> -~# <i>getseuser root system_u:system_r:crond_t</i> -seuser: root, level (null) -Context 0 root:sysadm_r:cronjob_t -Context 1 root:staff_r:cronjob_t -</pre> - -<p> -As you can see, the default context is always for the <c>root</c> SELinux user. -However, the <path>/var/spool/cron/crontabs/root</path> file context in the -above example is for the SELinux user staff_u. Hence, cron will not be able to -read this file (the <c>user_cron_spool_t</c> type is a UBAC constrained one). -</p> - -<p> -To fix this, change the user of the file to root: -</p> - -<pre caption="Change the SELinux user of the root crontab file"> -~# <i>chcon -u root /var/spool/cron/crontabs/root</i> -</pre> - -<p> -Another fix would be to disable UBAC completely. This is accomplished with -<c>USE="-ubac"</c>. -</p> - -</body> -</section> -<section id="missingdatum"> -<title>When querying the policy, I get 'ERROR: could not find datum for type ...'</title> -<body> - -<p> -When using <c>seinfo</c> or <c>sesearch</c> to query the policy on the system, -you get errors similar to: -</p> - -<pre caption="Triggering the 'could not find datum' error"> -~# <i>seinfo -tasterisk_t</i> -ERROR: could not find datum for type asterisk_t -</pre> - -<p> -This is most likely because your tools are using a newer binary policy to -enforce policy, but an older binary for querying. You can verify if this is the -case by listing the last modification time on the files: -</p> - -<pre caption="Checking last modification time of the policy files"> -~# <i>ls -ltr /etc/selinux/strict/policy/policy.*</i> -</pre> - -<p> -The file modified last should be the same one as returned by checking -<path>/selinux/policyvers</path>: -</p> - -<pre caption="Checking the runtime policy version"> -~# <i>cat /selinux/policyvers; echo</i> -24 -</pre> - -<p> -If this is not the case (which is very likely since you are reading this FAQ -entry) then try forcing the utilities policy version to the correct version: -</p> - -<pre caption="Editing semanage.conf"> -~# <i>vim /etc/selinux/semanage.conf</i> -<comment># Look for and uncomment the policy-version line and set it to the right version</comment> -policy-version = <i>24</i> -</pre> - -<impo> -If your system is upgrading its kernel, higher version(s) can be supported. In -this case, either unset the value again to automatically "jump" to a higher -version, or force set it to the higher version. -</impo> - -</body> -</section> -<section id="recoverportage"> -<title>Portage fails to label files because "setfiles" does not work anymore</title> -<body> - -<p> -Portage uses the <c>setfiles</c> command to set the labels of the files it -installs. However, that command is a dynamically linked executable, so any -update in its depending libraries (<path>libselinux.so</path>, -<path>libsepol.so</path>, <path>libaudit.so</path> and of course -<path>libc.so</path>) might cause for the application to fail. Gentoo's standard -solution (<c>revdep-rebuild</c>) will not work, since the tool will try to -rebuild policycoreutils, which will fail to install because Portage cannot set -the file labels. -</p> - -<p> -The solution is to rebuild policycoreutils while disabling Portage's selinux -support, then label the installed files manually using <c>chcon</c>, based on -the feedback received from <c>matchpathcon</c>. -</p> - -<pre caption="Recovering from Portage installation failures"> -# <i>FEATURES="-selinux" emerge --oneshot policycoreutils</i> -# <i>for FILE in $(qlist policycoreutils); do \ -CONTEXT=$(matchpathcon -n ${FILE}); chcon ${CONTEXT} ${FILE}; done</i> -</pre> - -<p> -Now Portage will function properly again, labeling files as they should. -</p> - -</body> -</section> -<section id="nosuid"> -<title>Applications do not transition on a nosuid-mounted partition</title> -<body> - -<p> -If you have file systems mounted with the <c>nosuid</c> option, then -applications started from these file systems will not transition into their -appropriate domain. This is intentional. -</p> - -<p> -So, a <c>passwd</c> binary, although correctly labeled <e>passwd_exec_t</e>, -will not transition into the <e>passwd_t</e> domain if the binary is stored on a -file system mounted with <c>nosuid</c>. -</p> - -</body> -</section> -<section id="auth-run_init"> -<title>Why do I always need to re-authenticate when operating init scripts?</title> -<body> - -<p> -When you, as an administrator, wants to launch or stop daemons, these activities -need to be done as <c>system_u:system_r</c>. Switching to this context set is a -highly privileged operation (since you are effectively leaving the user context -and entering a system context) and hence the default setup requires the user to -re-authenticate. -</p> - -<p> -You can ask not to re-authenticate if you use PAM by editing -<path>/etc/pam.d/run_init</path> and adding the following line on top: -</p> - -<pre caption="Setup run_init pam configuration to allow root not to re-authenticate"> -auth sufficient pam_rootok.so -</pre> - -<p> -With this in place, you can now prepend your init script activities with -<c>run_init</c> and it will not ask for your password anymore: -</p> - -<pre caption="Using run_init"> -# <i>run_init rc-service local status</i> -Authenticating swift. - * status: started -</pre> - -</body> -</section> -<section id="initramfs"> -<title>How do I use SELinux with initramfs?</title> -<body> - -<p> -We currently do not support booting in enforcing mode with an initramfs image -(but we are working on it). For the time being, boot in permissive mode. Once -booted, switch to enforcing mode (<c>setenforce 1</c>). -</p> - -<p> -If you run SELinux on a production system and would not like to have attackers -be able to switch back to permissive mode (even when they would have the -necessary privileges otherwise), set the <c>secure_mode_policyload</c> boolean. -When enabled, enforcing mode cannot be disabled anymore (until you reboot). -</p> - -<pre caption="Toggling secure_mode_policyload"> -# <i>setsebool secure_mode_policyload on</i> -</pre> - -</body> -</section> -<section id="xdm"> -<title>Logons through xdm (or similar) fail</title> -<body> - -<p> -If you log on through xdm, gdm, kdm, slim or any other graphical logon manager, -you might notice in permissive mode that your context is off, and in enforcing -mode that you just cannot log on. -</p> - -<p> -The reason of this is that PAM needs to be configured to include SELinux -awareness in your session handling: -</p> - -<pre caption="Updating pam setting for gdm"> -... -session required pam_loginuid.so -session optional pam_console.so -<i>session optional pam_selinux.so</i> -</pre> - -<p> -Replicate the calls towards <path>pam_selinux.so</path> in the various -<path>/etc/pam.d/gdm*</path> files (or similar depending on your graphical -logon manager). -</p> - -</body> -</section> -<section id="selinuxfs"> -<title>What is SELinuxfs and where should it be?</title> -<body> - -<p> -The selinuxfs is, as the name suggest, the SELinux File System. It is a -pseudo-filesystem, which means that it is represented through files and -directories, but those files or directories are not on your disk, but generated -by the Linux kernel every time you query it. -</p> - -<p> -The file system is used by the SELinux utilities as an interface to query the -SELinux state, maintained by the Linux kernel. -</p> - -<p> -Historically (before <path>libselinux-2.1.9</path>), the mount point for the -SELinux file system <e>had to be</e> <path>/selinux</path>. From -<path>libselinux-2.1.9</path> onwards, the default location where the file -system is looked for is <path>/sys/fs/selinux</path>, although the library still -falls back to the original <path>/selinux</path> location if it cannot find it -at the new place. -</p> - -<p> -However, the <path>/sys/fs/selinux</path> location currently has an issue for -those systems not using an initramfs, as it means that <path>/sys</path> has not -been mounted when <c>init</c> tries to mount <path>/sys/fs/selinux</path>. We -are working out how to resolve this, but for now, keep <path>/selinux</path> -active. -</p> - -</body> -</section> -</chapter> -</guide> 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> diff --git a/xml/selinux/hb-intro-enhancingsecurity.xml b/xml/selinux/hb-intro-enhancingsecurity.xml deleted file mode 100644 index 8a126c1..0000000 --- a/xml/selinux/hb-intro-enhancingsecurity.xml +++ /dev/null @@ -1,387 +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-enhancingsecurity.xml,v 1.3 2011/06/07 19:46:52 klondike Exp $ --> - -<sections> -<version>2</version> -<date>2011-05-25</date> - -<section> -<title>Introduction</title> -<subsection> -<title>A Warm Welcome</title> -<body> - -<p> -Welcome to the Gentoo SELinux handbook. In this resource, we will bring you up -to speed with Gentoo Hardened's implementation of SELinux and the policies -involved. Part of this exercise is to help you understand why SELinux was -brought to life and which concept is behind the development of the SELinux -patches. We will cover the SELinux concepts, the reference policy that Gentoo -Hardened uses and elaborate on how to work with the various SELinux tools. -</p> - -<p> -The purpose of this book is not to explain SELinux itself in great detail. There -are many references available on the Internet and in the better bookstores that -help you with the SELinux topic. Instead, we will focus on SELinux integration -within Gentoo Hardened. Of course, we will give a quick introduction to SELinux -to allow you to understand how it works, what it is and help you identify which -actions you will need to take in order to properly secure your system using the -SELinux tools. -</p> - -</body> -</subsection> -</section> -<section> -<title>Securing Linux</title> -<subsection> -<title>Security In General</title> -<body> - -<p> -Security is often seen as a vague concept. What is security in general? How do -you measure security? What is the benefit and how do you make sure you do not -put too much effort in securing your system? -</p> - -<p> -Well, security zealots will tell you that there is no such thing as too much -security. If properly implemented, security does not restrict functionality or -performance. It does not give you too much overhead in order to do your tasks. -But implementing security properly is a different and time-consuming task. That -is also why you often hear that security is as good as its administrator. -</p> - -<p> -So, how can you look at security? A good practice on security is to define your -security goals. List what you want to achieve and why. By tracking the threats -that you want to minimize, you build up a security model that is appropriate for -your environment. Such threats can be very broad, such as "Ensure no-one is able -to work around our security measures". -</p> - -<p> -In case of a Linux system powered with SELinux, this would at least mean that -you want to protect critical system files, such as kernel image(s) and boot -loader configuration, passwords and the SELinux policy binary itself from being -written by anyone or anything except trusted processes. -</p> - -</body> -</subsection> -<!-- Suggestion to remove from guide, more interesting for a generic security -document? -<subsection> -<title>Security on Operating System Level</title> -<body> - -<p> -So far for the high-level and theoretic explanation on security. What about -operating system security? -</p> - -<p> -On the Internet, you will find a multitude of documents helping you secure your -system. Some of these documents are procedure-driven (execute this, delete that, -change permissions of this file and that file) and are often found as security -best practices for operating systems or distributions. You can find such -documents on the project sites themselves (such as the <uri -link="/doc/en/security/security-handbook.xml">Gentoo Security Handbook</uri>) or -on specialized sites of organizations that keep track of secure configuration -baselines in general (such as <uri -link="http://www.cisecurity.org">CISecurity</uri>'s benchmark documents). -Others are higher-level descriptions (often called frameworks) that help you -focus on the various fields in which security plays a role. -</p> - -<p> -A simple example of such higher-level descriptions can be seen in the CoBIT -framework, which has a process called <e>Ensure Systems Security</e> which -defines (at least) the following control objectives: -</p> - -<ol> - <li>Manage Security Measures</li> - <li>Identification, Authentication and Access</li> - <li>Security of Online Access to Data</li> - <li>User Account Management</li> - <li>Management Review of User Accounts</li> - <li>User Control of User Accounts</li> - <li>Security Surveillance</li> - <li>Data Classification</li> - <li>Central Identification and Access Rights Management</li> - <li>Violation and Security Activity Reports</li> - <li>Incident Handling</li> - <li>Re-accreditation</li> - <li>Counterparty Trust</li> - <li>Transaction Authorization</li> - <li>Non-repudiation</li> - <li>Trusted Path</li> - <li>Protection of Security Functions</li> - <li>Cryptographic Key Management</li> - <li>Malicious Software Preventions, Detection and Correction</li> - <li>Firewall Architectures and Connections with Public Networks</li> - <li>Protection of Electronic Value</li> -</ol> - -<p> -If your head is not spinning yet, then I suggest to dive deeper into these -subjects. However, for this handbook, we'll leave it at this and focus on those -topics that are relevant for further SELinux discussions. -</p> - -</body> -</subsection> -<subsection> -<title>Operating System Security Best Practices</title> -<body> - -<p> -To properly secure any operating system, there are a few best practices that you -might need to keep in mind. They do not cover the full spectrum of configuration -directives or requirements, but if you do not implement those properly, you risk -that the threats facing your system become reality faster. -</p> - -<dl> - <dt>Only run necessary services</dt> - <dd> - Only run services (scripts, daemons, jobs, servers ...) of which you know - you need them. Regularly verify your system runtime behavior to see if no - services are running that you don't need. The more services that run, the - more <e>access vectors</e> intruders or malicious people have towards your - system. - </dd> - <dt>Update your system regularly</dt> - <dd> - Updating your system will resolve all potential vulnerabilities of software - you have if they were known by the developers and fixed in later versions. - Some distributions, including Gentoo, allow you to pull in only - security-related updates so that your upgrade cycle is not too time and - resource consuming. See <c>glsa-check</c> for more information on how to do - this with Gentoo. - </dd> - <dt>Do not use privileged accounts</dt> - <dd> - For each task you execute on a system, make sure that that task has the - least amount of privileges needed to get to its goal. Only a few services - will require root privileges (Unix/Linux' highest privileged account), but - other accounts might also be seen as privileged (such as accounts that have - password-less <c>sudo</c> rights, or accounts that are in the <e>wheel</e> - group. The same is true for your regular day-to-day tasks. - </dd> - <dt>Implement a good password policy</dt> - <dd> - Make sure that your passwords are not easy to guess or to brute-force. If - your system uses passwords for authentication and the password is - compromised, security is completely compromised as well as, as far as the - system knows, the malicious user that is using your password is you. - </dd> - <dt>Configure your services properly</dt> - <dd> - Do not trust services to come with a good, default configuration. Most - default configurations are so that the majority of users can use the service - (feature-wise), which might not always be the proper configuration for you. - </dd> - <dt>Use proper permissions</dt> - <dd> - Make sure your files are properly protected permission-wise. Never use - world-readable files and only allow other accounts to read (or modify) your - file(s) if they need to. Use group-permissions wisely and often validate - group membership. If file systems can be used in a read-only fashion, do so. - If you do not need to access a particular file system by default, don't - mount it. - </dd> -</dl> - -<p> -This is just a subset of best practices. One of the aspects within an operating -system setup is the method of <e>accessing</e> the system, services or data. -Implementing a good access control is mandatory from a systems' security -point-of-view. -</p> - -</body> -</subsection> ---> -<subsection> -<title>Access Control</title> -<body> - -<p> -A decent access control system (or group of systems) ensures that only -authorized individuals or processes are granted access to the resources they are -tring to work with. -</p> - -<p> -Before one can implement an access control system, you first need to have proper -authentication in place. If your authentication schemes are flawed, your access -control system might not be able to differentiate legitimate users from -malicious ones. -</p> - -<p> -Authenticating users within Linux is often done through PAM (<e>Pluggable -Authentication Modules</e>), a powerful mechanism to integrate multiple -low-level authentication schemes into a high-level interface. -</p> - -<p> -Authorizing access to resources however is often done through a simple -permission scheme. Most resources are not hidden by default, although -patches and updates exist (such as those offered by Gentoo Hardened's -kernel sources with grSecurity patches which includes support for this -kind of measures). File-system wise, you can hide the existence of files -by ensuring the directory in which the file resides is not readable nor -"executable" by unauthorized accounts. -</p> - -<p> -This default permission scheme has major drawbacks. It does not allow you to -define very flexible authorizations (it only allows permissions on three levels: -owner, group-owner and everybody else) and is limited to read/write/execute -rights (although a few additional attributes are supported nowadays as well). -</p> - -<p> -Another drawback is that the permission scheme is <e>discretionary</e>, meaning -that users and processes are able to change the security policy in place. -</p> - -<p> -For the majority of uses, this permission scheme is sufficient and has proven to -offer a decent method for managing access authorizations. But the drawbacks have -shown to be a major hole in the Linux' offering. -</p> - -</body> -</subsection> -</section> -<section> -<title>Mandatory Access Control</title> -<subsection> -<title>Enter SELinux</title> -<body> - -<p> -If the above mentioned discretionary access control, abbreviated to <e>DAC</e>, -is not sufficient (and if you are keen on security, you will not find it -sufficient), you need a <e>Mandatory</e> Access Control, or <e>MAC</e> system. -</p> - -<p> -When using a MAC system, activities that a process wants to perform on another -resource need to be explicitly allowed. It offers a higher granularity on -permissions as well as resources. They often support not only files, but also -sockets, ports, memory segments, queues, processes, kernel services, system -calls, devices, file systems and more. The granularity of activities supported -is also quite large. For files, this can be append, create, execute, write, -link, ioctl, get- and setattr, read, rename, lock, ... whereas for sockets this -might be append, bind, connect, create, write, sendto, accept, ... Also, when -using a MAC system, no user or process can manipulate the security policy -itself: what the security administrator has defined cannot be overturned. -</p> - -<p> -This is where SELinux comes to play. SELinux is a Linux kernel feature which -implements, amongst other things, a MAC system for controlling and governing -access to various resources. It uses a deny-by-default permission scheme, so any -access that a process wants to perform needs to be explicitly granted. -</p> - -<p> -SELinux also allows you to put a finer-grained permission model <b>on top -of</b> the traditional DAC system (which is still in use when using SELinux -- in other words, if the traditional system does not allow certain activities, -it will not be allowed even if there are SELinux policies granting the -permission). -</p> - -</body> -</subsection> -<subsection> -<title>What is SELinux</title> -<body> - -<p> -To support this finer-grained permission model, you would think that changes -are needed to the Linux kernel. Yet thanks to the Linux kernel <e>LSM</e> -interface (<e>Linux Security Modules</e>), support for SELinux was easily added -and since the 2.6 kernel series, SELinux has been integrated in the mainstream -kernel release. But supporting SELinux and using SELinux are very different topics. -</p> - -<p> -In order to properly identify resources, SELinux needs to assign labels to these -resources. When the resources are in-memory, this is mostly supported by the -Linux kernel itself, but for persistent resources such as files, these labels -need to be placed somewhere. SELinux has chosen to use a file's extended -attributes (which is stored on the file system itself). The advantage here is -that a label remains on the file even if the file is renamed. A disadvantage of -this approach is that the file system must support <e>extended attributes</e>, -which not all file systems do (or have activated). -</p> - -<p> -SELinux also uses roles to govern resource access. A user that does not have -access to the system administration role should never be allowed to execute any -system administration activities even if he is able to escalate its privileges -(say through a set-uid application). To support roles, SELinux requires changes -to the authentication services (PAM) and needs to store role definitions and -authorizations somewhere. -</p> - -<p> -Next to the kernel support and labels assigned to the resources and support -within the authorization system, SELinux also requires particular tools to -support the SELinux features. Examples are administrative tools to view and -manipulate labels, privilege management tools (like <c>sudo</c>), system -services (like SysVInit) etc. This is reflected in a set of patches -against these (and more) tools which are not always part of the applications' -main source code. -</p> - -</body> -</subsection> -<subsection> -<title>Gentoo Hardened and SELinux</title> -<body> - -<p> -What Gentoo Hardened offers is SELinux integrated in the distribution. When you -select SELinux support, Gentoo Hardened will apply the necessary patches against -the applications and help you (re)label your files and other resources to become -SELinux-manageable. Gentoo Hardened also integrates SELinux support inside -Portage, allowing for newly installed files to be automatically labeled and to -use a SELinux-supporting sandbox environment for -safe package building. -</p> - -<p> -Next to the pure technological support, we hope that you will also find the -necessary supporting documents, guides, experience and on-line support for using -SELinux within Gentoo. Never hesitate to come and say hi on the -<c>#gentoo-hardened</c> chat channel in the Freenode IRC network or on our -mailing lists. -</p> - -<p> -If you believe that SELinux is the right thing for you and you want to try it -out using Gentoo Hardened, please read on. The next chapter will inform you how -SELinux security is "designed" and how it is conceptually structured. Further -chapters will then help you with the authorization language and the "base" -policies that most distributions start from, and finally help you install, -run and manage a SELinux hardened Gentoo system. -</p> - -</body> -</subsection> -</section> -</sections> diff --git a/xml/selinux/hb-intro-referencepolicy.xml b/xml/selinux/hb-intro-referencepolicy.xml deleted file mode 100644 index 566dc00..0000000 --- a/xml/selinux/hb-intro-referencepolicy.xml +++ /dev/null @@ -1,255 +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-referencepolicy.xml,v 1.3 2011/06/07 19:46:52 klondike Exp $ --> - -<sections> -<version>1</version> -<date>2011-06-02</date> - -<section> -<title>About SELinux Policies</title> -<subsection> -<title>SELinux Policy Language</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> -For instance, the allow-rule to allow all regular users (which are in the -user_t domain) to execute files with the bin_t label: -</p> - -<pre caption="Allow rule to execute bin_t files"> -allow user_t bin_t:file { read execute open }; -</pre> - -<p> -Other supported rules are -</p> - -<ul> - <li> - <e>dontaudit</e> will disable the logging of the denial message(s) - </li> - <li> - <e>auditallow</e> will allow the access but will also log it (by default, - allowances are not logged) - </li> - <li> - <e>neverallow</e> forces that a certain allow rule cannot be granted. Even - though SELinux is a positive security model (white listing), sometimes - neverallow rules might be needed. But generally you will not often see them. - </li> -</ul> - -<p> -As you can imagine, defining the rules for an entire system is very -resource-intensive if you want to do it right. It not only requires a deep -insight in how the system works, but also a lot of rule writing and testing. But -even more time consuming is that you will write the same rules over and over -again for different domains. To help developers with policy writing, a -<e>reference policy</e> has been brought to life with the following required -functionalities: -</p> - -<ul> - <li> - development of SELinux policy rules should be centralized even for different - distributions - </li> - <li> - a macro language should be supported that makes it easier to write new - policies - </li> - <li> - the policies should be modular, allowing for additional rules to be added or - removed - </li> -</ul> - -<p> -By centralizing the SELinux policy rule development, SELinux users will have the -same domain naming conventions as on other distributions. This makes debugging a -lot easier, documenting a lot less distribution-specific and makes it a bit -easier for end users to get acquainted with SELinux. -</p> - -</body> -</subsection> -<subsection> -<title>Tresys Reference Policy</title> -<body> - -<p> -The reference policy by choice is the <uri -link="http://oss.tresys.com/projects/refpolicy">Tresys SELinux Reference -Policy</uri>. This reference policy - currently at major version 2 - 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. -</p> - -<p> -The reference policy starts off with a <e>base</e> policy called -<path>base.pp</path>. This is a collection of policies needed to get a system up -and running and also offers the necessary functions towards the policy modules. -In Gentoo Hardened, this base policy is offered by <c>selinux-base-policy</c>. -</p> - -<p> -The policy modules themselves also use the <path>.pp</path> extension, but are -named more appropriately towards their content. For instance, the policy module -that contains all policy rules for the <c>screen</c> application is called -<path>screen.pp</path>. However, don't count on all policy modules to be named -after the tool: the policy module that contains the <c>wpa_supplicant</c> -specific rules is called <path>networkmanager.pp</path>. In Gentoo Hardened, the -modular policies are available in the <path>sec-policy</path> category and are -named <path>selinux-<module></path>. -</p> - -<p> -To get a list of running modules, run <c>semodule</c>: -</p> - -<pre caption="Listing the running SELinux policy modules"> -~# <i>semodule -l</i> -dbus 1.14.0 -dnsmasq 1.9.0 -hal 1.13.0 -[...] -</pre> - -</body> -</subsection> -<subsection> -<title>Toggle Policy States</title> -<body> - -<p> -As policies are built off from a "deny all" perspective, you can imagine that -there are thousands of rules already available in the reference policy. -Sometimes the developers know that particular rules will be active on one system -and inactive on another. Although this can be accomplished by developing two -different modules, SELinux development has opted to support <e>SELinux -booleans</e>. -</p> - -<p> -SELinux booleans allow for rules to be conditionally applied, based on the -administrator's requirements. You can get a list of supported booleans through -<c>getsebool</c>: -</p> - -<pre caption="Getting a list of supported booleans and their current state"> -~# <i>getsebool -a</i> -allow_execheap --> off -allow_execmem --> off -[...] -fcron_crond --> off -global_ssp --> on -[...] -</pre> - -<p> -If you need to change a boolean, you can use <c>togglesebool</c> to switch its -value, or <c>setsebool</c> so explicitly set its state: -</p> - -<pre caption="Toggling boolean states"> -~# <i>getsebool user_dmesg</i> -user_dmesg --> off -~# <i>togglesebool user_dmesg</i> -user_dmesg: active -<comment>(Now, the state is set to 'on')</comment> -~# <i>getsebool user_dmesg</i> -user_dmesg --> on -<comment>(Explicitly set the value to 'off')</comment> -~# <i>setsebool user_dmesg off</i> -</pre> - -</body> -</subsection> -<subsection> -<title>Policy Files and Locations</title> -<body> - -<p> -On Gentoo Hardened, the SELinux policy files are stored in -<path>/usr/share/selinux/strict</path> or -<path>/usr/share/selinux/targeted</path> (depending on your SELinux -configuration). Within this location, you will find: -</p> - -<ul> - <li> - a file called <path>base.pp</path>, which is the SELinux base policy, - </li> - <li> - one or more files with extension <path>.pp</path>, which are the SELinux - policy modules, and - </li> - <li> - an <path>include/</path> folder which contains the necessary files for - SELinux module developers to build additional modules for this system - </li> -</ul> - -</body> -</subsection> -<subsection> -<title>Policy 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. If you would run -<c>sestatus</c> now, you'll notice that we are using policy version 24. 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> -</sections> diff --git a/xml/selinux/hb-intro-resources.xml b/xml/selinux/hb-intro-resources.xml deleted file mode 100644 index 488d72b..0000000 --- a/xml/selinux/hb-intro-resources.xml +++ /dev/null @@ -1,111 +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-appendix-reference.xml,v 1.4 2011/06/09 17:37:45 klondike Exp $ --> - -<sections> -<version>2</version> -<date>2011-05-31</date> - -<section> -<title>Background</title> -<subsection> -<title>Introduction to SELinux</title> -<body> - -<ul> - <li> - <uri link="http://www.nsa.gov/research/_files/selinux/papers/inevit-abs.shtml">The Inevitability of Failure: - The Flawed Assumption of Security in Modern Computing Environments</uri> - explains the need for mandatory access controls. - </li> - <li> - <uri link="http://www.nsa.gov/research/_files/selinux/papers/flask-abs.shtml">The Flask Security Architecture: - System Support for Diverse Security Policies</uri> - explains the security architecture of Flask, the architecture used by SELinux. - </li> - <li> - <uri link="http://www.nsa.gov/research/_files/selinux/papers/module-abs.shtml">Implementing SELinux as a Linux Security Module</uri> - has specifics about SELinux access checks in the kernel. - </li> -</ul> - -</body> -</subsection> -</section> -<section> -<title>SELinux Policy</title> -<subsection> -<title>Policy Related References</title> -<body> - -<ul> - <li> - <uri link="http://www.nsa.gov/research/_files/selinux/papers/policy2-abs.shtml">Configuring the SELinux Policy</uri> - </li> - <li> - <uri link="http://oss.tresys.com/projects/refpolicy">SELinux Reference Policy</uri> - </li> - <li> - SELinux <uri link="http://www.selinuxproject.org/page/ObjectClassesPerms">Object Classes and Permissions</uri> Overview - </li> -</ul> - -</body> -</subsection> -</section> -<section> -<title>Books</title> -<subsection> -<title>Paper Books</title> -<body> - -<ul> - <li> - <c>SELinux by Example: Using Security Enhanced Linux</c>, Frank Mayer, - Karl MacMillan, and David Caplan, Prentice Hall, 2006; ISBN 0131963694 - </li> - <li> - <c>SELinux: NSA's Open Source Security Enhanced Linux</c>, Bill McCarty, - O'Reilly Media, 2004; ISBN 0596007167 - </li> -</ul> - -</body> -</subsection> -</section> - -<section> -<title>Gentoo Specific Resources</title> -<subsection> -<title>Gentoo Hardened</title> -<body> - -<p> -The following resources are specific towards Gentoo Hardened's SELinux -implementation. -</p> - -<ul> - <li> - <uri link="/proj/en/hardened/selinux-faq.xml">SELinux Frequently Asked - Questions</uri> - </li> - <!-- - <li> - <uri link="/proj/en/hardened/selinux-development.xml">SELinux Development - Guidelines</uri> - </li> - <li> - <uri link="/proj/en/hardened/selinux-policy.xml">SELinux Policy</uri> - </li> - --> -</ul> - -</body> -</subsection> -</section> -</sections> diff --git a/xml/selinux/hb-intro-virtualization.xml b/xml/selinux/hb-intro-virtualization.xml deleted file mode 100644 index cf082e0..0000000 --- a/xml/selinux/hb-intro-virtualization.xml +++ /dev/null @@ -1,25 +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-virtualization.xml,v 1.2 2011/04/25 20:12:59 zorry Exp $ --> - -<sections> -<version>0</version> -<date>2010-12-01</date> - -<section> -<title>TODO</title> -<subsection> -<body> - -<p> -This is a place-holder for future expansion. -</p> - -</body> -</subsection> -</section> -</sections> diff --git a/xml/selinux/hb-using-commands.xml b/xml/selinux/hb-using-commands.xml deleted file mode 100644 index ae55d83..0000000 --- a/xml/selinux/hb-using-commands.xml +++ /dev/null @@ -1,492 +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-using-commands.xml,v 1.3 2011/06/07 19:46:52 klondike Exp $ --> - -<sections> -<version>6</version> -<date>2011-10-15</date> - -<section> -<title>SELinux Information Commands</title> -<subsection> -<title>Introduction</title> -<body> - -<p> -You should currently have a SELinux enabled system (but running in permissive -mode, so it will not enforce its policy rules). So before we introduce you to -the world of SELinux and how you can add more rules to make sure your system -remains functional when you switch to enforcing mode, we first give a quick -overview of the various SELinux related commands. -</p> - -<p> -We start off with state commands where you can get global information on SELinux -state (is it running in enforcing mode or not, versions etc.) -</p> - -</body> -</subsection> -<subsection> -<title>Getting SELinux Status</title> -<body> - -<p> -The first command we will talk about is <c>sestatus</c>. -</p> - -<pre caption="Running sestatus"> -# <i>sestatus</i> -SELinux status: enabled -SELinuxfs mount: /selinux -Current mode: permissive -Mode from config file: permissive -Policy version: 24 -Policy from config file: strict -</pre> - -<p> -The output of this command shows you that SELinux is enabled and is currently in -the <e>permissive</e> mode. It also tells you that the system is configured to -run in <e>strict</e> mode - so no unconfined_t domain here. -</p> - -<p> -The <c>sestatus</c> command also has an extended output if you run it with the -<c>-v</c> option. When this is done, the command returns the contexts of -important processes and files: -</p> - -<pre caption="Running sestatus -v"> -# <i>sestatus -v</i> -SELinux status: enabled -SELinuxfs mount: /selinux -Current mode: enforcing -Mode from config file: enforcing -Policy version: 24 -Policy from config file: strict - -Process contexts: -Current context: staff_u:sysadm_r:sysadm_t -Init context: system_u:system_r:init_t -/sbin/agetty system_u:system_r:getty_t -/usr/sbin/sshd system_u:system_r:sshd_t - -File contexts: -Controlling term: staff_u:object_r:user_devpts_t -/sbin/init system_u:object_r:init_exec_t -/sbin/agetty system_u:object_r:getty_exec_t -/bin/login system_u:object_r:login_exec_t -/sbin/rc system_u:object_r:rc_exec_t -/usr/sbin/sshd system_u:object_r:sshd_exec_t -/sbin/unix_chkpwd system_u:object_r:chkpwd_exec_t -/etc/passwd system_u:object_r:etc_t -/etc/shadow system_u:object_r:shadow_t -/bin/sh system_u:object_r:bin_t -> system_u:object_r:shell_exec_t -/bin/bash system_u:object_r:shell_exec_t -/usr/bin/newrole system_u:object_r:newrole_exec_t -/lib/libc.so.6 system_u:object_r:lib_t -> system_u:object_r:lib_t -/lib/ld-linux.so.2 system_u:object_r:lib_t -> system_u:object_r:ld_so_t -</pre> - -<p> -Another general SELinux status command is <c>getenforce</c>, which allows you to -quickly see if your SELinux is running in enforcing mode (SELinux policies are -enforced), permissive (SELinux policies are checked and logged, but not -enforced) or disabled (SELinux policy is not loaded and thus not checked). -</p> - -<pre caption="Using the getenforce command"> -# <i>getenforce</i> -Enforcing -</pre> - -</body> -</subsection> -<subsection> -<title>Getting SELinux Object Information</title> -<body> - -<p> -Next on the table is the <c>seinfo</c> command. This command allows you to query -the running policy for all objects (types, roles, attributes, users, booleans -...) defined. -</p> - -<p> -Common usages are: -</p> - -<ul> - <li> - checking if a specific domain is defined on your system (in case you're - wondering if you need to load an additional SELinux policy module or not) - </li> - <li> - checking which domains a particular role can be in (in case you're wondering - if your regular users are allowed by SELinux policies to even be - transitioned towards a specific domain) - </li> - <li> - checking which attributes are assigned to a specific domain (or vice versa, - which domains have a specific attribute set) as some SELinux policy rules - work on attributes rather than domains - </li> -</ul> - -<p> -As an example, we query if the crontab_t domain is known, if the user_r role can -use the contab_t domain and finally which domains have the cron_spool_type -attribute set. -</p> - -<pre caption="Using seinfo"> -# <i>seinfo -tcrontab_t</i> - crontab_t -# <i>seinfo -ruser_r -x</i> - user_r - Dominated Roles: - user_r - Types: - [...] - crontab_t - [...] -# <i>seinfo -acron_spool_type -x</i> - cron_spool_type - user_cron_spool_t - system_cron_spool_t -</pre> - -</body> -</subsection> -<subsection> -<title>Querying SELinux Policy Rules</title> -<body> - -<p> -A command which you will often use is <c>sesearch</c>. This command allows you -to query the current policy allow rules and is a huge help when trying to find -out if something is allowed (or why something isn't allowed). -</p> - -<p> -The <c>sesearch</c> command is most often used with a source domain (<c>-s</c>), -target domain (<c>-t</c>) or both, the class for which you want to query allow -rules for (file, dir, socket, process ...) and the privilege you want to query -for (read, write, open, transition, execute ...). -</p> - -<p> -For instance, to find out which domains can write the files that have the -shadow_t domain: -</p> - -<pre caption="Querying allow rules with sesearch"> -# <i>sesearch -t shadow_t -c file -p write -A</i> -Found 8 semantic av rules: - [...] - allow portage_t shadow_t : file { ioctl read write ... }; - allow useradd_t shadow_t : file { ioctl read write ... }; - ... -</pre> - -<p> -You will notice that there are sometimes results based on attributes rather than -domains: -</p> - -<pre caption="Allow rule based on attribute"> - allow portage_t file_type : file { ioctl read write ... }; -</pre> - -<p> -In this case, the source domain (portage_t) is allowed to write to files whose -domain have the file_type attribute set. If you get the feeling of these things, -you'll wonder if the above rule is not a flagrant security issue as almost all -domains for files have the file_type set. Yes and no - if we take a look at -which domains have file write privileges to file_type domains, you'll notice -that this is only portage: -</p> - -<pre caption="Querying domains with file-write privileges to file_type domains"> -# <i>sesearch -t file_type -c file -p write -A -d</i> -Found 1 semantic av rules: - allow portage_t file_type : file { ioctl read write ... }; -</pre> - -<p> -Note that we had one command without the <c>-d</c> option and one with. When -<c>-d</c> is given, the search will perform an exact search without resolving -the attributes. When <c>-d</c> is not given, it will resolve the attribute. In -the last command example, dropping <c>-d</c> would result in hundreds of allow -rules: for each domain that has file_type set, the search tries to find rules -that allow file-write access to that particular domain. -</p> - -<p> -Another interesting functionality of the <c>sesearch</c> command is to show you -the rules that are applicable depending on the state of a boolean. If you want -to query on a particular boolean, use <c>-b</c>. If you want to see the logic -that the policy uses, use <c>-C</c> (and yes, both can be combined). -</p> - -<p> -As an example, we'll check what we allow (or deny) when the <c>global_ssp</c> -boolean is set: -</p> - -<pre caption="Checking the policy regarding the global_ssp boolean"> -# <i>sesearch -b global_ssp -A -C -d</i> -Found 2 semantic av rules: -ET allow domain device_t : dir { getattr search open } ; [ global_ssp ] -ET allow domain urandom_device_t : chr_file { ioctl read getattr lock open } ; [ global_ssp ] -</pre> - -<p> -The prefix you see shows two letters, relating to two important definitions: -</p> - -<ul> - <li> - Is the rule currently <b>E</b>nabled or <b>D</b>isabled? - </li> - <li> - Does the boolean need to be set to <b>T</b>rue or <b>F</b>alse to enable the rule? - </li> -</ul> - -</body> -</subsection> -<subsection> -<title>Getting Security Context Information</title> -<body> - -<p> -During administrative tasks, and especially when you are checking if a SELinux -denial could be made, it is important to find out what the security context is -for a particular resource. Luckily, Gentoo Hardened - if properly installed - -has already patched some tools to allow you to get this information using your -standard tools. -</p> - -<p> -To get the security context of a file, use <c>ls -Z</c>: -</p> - -<pre caption="Getting a file security context"> -~$ <i>ls -Z /etc/make.conf</i> -system_u:object_r:portage_conf_t /etc/make.conf -</pre> - -<p> -To get the security context of a process, use <c>ps -Z</c>: -</p> - -<pre caption="Getting a process security context"> -# <i>ps -Z $(pidof init)</i> -LABEL PID TTY STAT TIME COMMAND -system_u:system_r:init_t 1 ? Ss 0:00 init [3] -</pre> - -<p> -To get the security context of the current user, use <c>id -Z</c>: -</p> - -<pre caption="Getting a user security context"> -~$ <i>id -Z</i> -staff_u:staff_r:staff_t -</pre> - -</body> -</subsection> -</section> -<section> -<title>Managing SELinux</title> -<subsection> -<title>Introduction</title> -<body> - -<p> -Managing SELinux objects (booleans, users, ports, contexts ...) is most often -done using <c>semanage</c>. As this application offers the interface towards -various SELinux configurations, we dedicate an entire section on it, but will -also cover the commands that offer similar functionality (and are sometimes -easier to remember). -</p> - -</body> -</subsection> -<subsection> -<title>Booleans</title> -<body> - -<p> -We have already covered SELinux booleans earlier in this book as well as the -<c>getsebool</c> and <c>setsebool</c> commands. With <c>semanage</c> you can too -manage the booleans and, as an added bonus, listing the booleans will also show -the description of the boolean (even though there is still work to be done in -this area). -</p> - -<pre caption="Listing the available SELinux booleans"> -# <i>semanage boolean -l</i> -SELinux boolean Description - -allow_ptrace -> off allow_ptrace -rsync_export_all_ro -> off rsync_export_all_ro -</pre> - -<note> -As you will notice, most descriptions are just the boolean name, but you will -find more and more booleans with a better description as you get acquainted with -- and install more - SELinux policy modules. -</note> - -<p> -You can set a boolean with both <c>setsebool</c> and <c>semanage</c>: -</p> - -<pre caption="Setting SELinux boolean values"> -# <i>semanage boolean -m --on -F user_dmesg</i> -</pre> - -</body> -</subsection> -<subsection id="users"> -<title>SELinux Users and Logins</title> -<body> - -<p> -SELinux users and logins are different from Unix accounts. SELinux logins allow -you to map a Unix account to a SELinux user: -</p> - -<pre caption="Listing the SELinux logins"> -# <i>semanage login -l</i> -Login Name SELinux User - -__default__ user_u -root root -swift staff_u -system_u system_u -</pre> - -<p> -The default behavior is that users are logged on as the <e>user_u</e> SELinux -user. This SELinux user is a non-administrator user: it has no specific -privileges and should be used for every account that never requires elevated -privileges (so no <c>su</c> or <c>sudo</c> rights for anything). -</p> - -<p> -The account you use to administer your system should be mapped to the -<c>staff_u</c> SELinux user (or its own user with the appropriate roles). This -can be accomplished as follows (example with the Unix account <e>anna</e>): -</p> - -<pre caption="Letting 'anna' log on as 'staff_u'"> -# <i>semanage login -a -s staff_u anna</i> -</pre> - -<impo> -Make sure that whatever account you use to administer your system is mapped to -the <c>staff_u</c> user, or has the ability to switch to the <c>sysadm_r</c> -role. Portage only works from within the <c>sysadm_r</c> role. -</impo> - -<p> -As mentioned, SELinux users are configured to be able to join in on one or more -roles. To list the available roles, you can use <c>semanage user -l</c>: -</p> - -<pre caption="Listing login / role mappings"> -# <i>semanage user -l</i> -SELinux User SELinux Roles - -root staff_r sysadm_r -staff_u staff_r sysadm_r -[...] -</pre> - -</body> -</subsection> -<subsection> -<title>Managing Ports</title> -<body> - -<p> -Even network ports (like port 22 for SSH) are 'protected' by SELinux. To get an -overview of which domains are assigned to which ports (or port ranges) use -<c>semanage port -l</c>. -</p> - -<pre caption="Listing SELinux managed ports"> -# <i>semanage port -l | grep '22$'</i> -ssh_port_t tcp 22 -</pre> - -</body> -</subsection> -</section> - -<section> -<title>Using SELinux</title> -<subsection> -<title>Introduction</title> -<body> - -<p> -Up until now we've covered getting SELinux related information as well as -managing SELinux settings. However, users on a SELinux hardened system will also -need to know a few things about working with SELinux, including (but not limited -to) roles and role transitions. -</p> - -</body> -</subsection> -<subsection> -<title>Switching Roles</title> -<body> - -<p> -As a type enforcement access control system, SELinux allows particular roles to -be within a set of domains. If you are using a role which is not allowed within -a particular domain, you will not be successful in using that domain and will be -denied the actions assigned to that domain. -</p> - -<p> -If your standard users are all SELinux user_u users (with the only supported -role being user_r) then those users will never need to switch roles (nor are -they allowed to). But users that are staff_u (or other users that have multiple -roles) those users should be made clear how they switch between roles. We have -already covered how to map such users to the correct SELinux user (see <uri -link="#users">SELinux Users and Logins</uri>). -</p> - -<p> -The command that accomplishes switching roles is called <c>newrole</c>. It's -use is pretty straight forward. -</p> - -<pre caption="Using newrole"> -~$ <i>newrole -r sysadm_r</i> -Password: <comment>(Enter the users' password - not root's!)</comment> -</pre> - -<p> -When performing a role transition, SELinux will ask the user to re-authenticate -through its users' password. If you are logged on as a regular user and used -<c>su</c> or <c>sudo</c> to become the root user, then <c>newrole</c> will still -require you to enter the regular users' password. -</p> - -</body> -</subsection> -</section> - -</sections> diff --git a/xml/selinux/hb-using-configuring.xml b/xml/selinux/hb-using-configuring.xml deleted file mode 100644 index 8a87b54..0000000 --- a/xml/selinux/hb-using-configuring.xml +++ /dev/null @@ -1,981 +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-using-permissive.xml,v 1.3 2011/06/07 19:46:52 klondike Exp $ --> - -<sections> -<version>1</version> -<date>2011-09-30</date> - -<section> -<title>Administering Users</title> -<subsection> -<title>Introduction</title> -<body> - -<p> -During the installation, we already covered how to map a Linux user to a SELinux -user. In the example, we used a hypothetical user "john" and mapped him to the -SELinux user "staff_u". If you are running a multi-user system, managing the -right mappings is important. A user that is mapped to the SELinux user "user_u" -will not get any additional rights. Even if you would give that user additional -rights through commands such as <c>sudo</c>, the SELinux policy will not allow -this user to do anything that is administration related. -</p> - -<p> -For this reason, it is important to go over the SELinux user mappings and the -Linux users on your system. -</p> - -</body> -</subsection> -<subsection> -<title>User Mappings</title> -<body> - -<p> -Run <c>semanage login -l</c> to show the current mappings between Linux logins -and SELinux users. -</p> - -<pre caption="Running semanage login -l"> -# <i>semanage login -l</i> - -Login Name SELinux User - -__default__ user_u -root root -john staff_u -system_u system_u -</pre> - -<p> -The "user_u" SELinux user is for regular accounts. As such, the special -<e>__default__</e> mapping is defined by SELinux to denote every login that is -not defined otherwise. This makes sure that a newly defined account does not get -elevated privileges by default. -</p> - -<p> -The next table gives an overview of the standard SELinux users available after -an installation. -</p> - -<table> -<tr> - <th>SELinux User</th> - <th>Description</th> -</tr> -<tr> - <ti>user_u</ti> - <ti> - Default regular SELinux user, which should be used by end-user accounts that - are not going to administer any service(s) on the system - </ti> -</tr> -<tr> - <ti>staff_u</ti> - <ti> - SELinux user for administrators. This user has the right to switch roles and - as such gain elevated privileges - </ti> -</tr> -<tr> - <ti>root</ti> - <ti> - SELinux user for the root account. It differs little from the staff_u - account beyond being a different ID. This ensures that files protected by - the user based access control for root cannot be handled by the staff_u - (and other) users - </ti> -</tr> -<tr> - <ti>sysadm_u</ti> - <ti> - SELinux user for system administration. By default, this account is not - immediately used as this user immediately gets the administrative role - (whereas staff_u and root still need to switch roles). - </ti> -</tr> -<tr> - <ti>system_u</ti> - <ti> - SELinux user for system services. It should never be used for end users or - administrators as it provides direct access to the system role (and - privileges) - </ti> -</tr> -<tr> - <ti>unconfined_u</ti> - <ti> - Used when the policy is <e>targeted</e>, this SELinux user has many - privileges (it is essentially not limited in its actions, although it is - still handled through SELinux - just through a "wide open" policy). - </ti> -</tr> -</table> - -<p> -To map a user to a specific SELinux user, use <c>semanage login -a</c>: -</p> - -<pre caption="Mapping a user 'sophie' to the staff_u user"> -# <i>semanage login -a -s staff_u sophie</i> -</pre> - -<p> -However, when you update such mapping, the files in that users' home directory -will be owned by a wrong SELinux user. It is therefor important to relabel the -files of that user: -</p> - -<pre caption="Relabeling sophie's files"> -# <i>restorecon -R -F /home/sophie</i> -</pre> - -</body> -</subsection> -<subsection> -<title>Additional SELinux Accounts</title> -<body> - -<p> -It is perfectly possible to create additional SELinux accounts, and then map the -Linux logins to these new accounts. This can be necessary when you want a more -thorough auditing (on end user level) or when you will be enhancing the policy -with additional roles. Also, if you want to use the User Based Access Control -feature, using different SELinux users is important to enforce the control on -different users (if they all use the same SELinux user, then UBAC has little to -no effect). -</p> - -<p> -Managing the SELinux accounts is done through <c>semanage user</c>: -</p> - -<pre caption="Creating a SELinux user"> -# <i>semanage user -a -R "staff_r sysadm_r" sophie</i> -</pre> - -<p> -Let's verify how the SELinux users are currently configured: -</p> - -<pre caption="Checking the SELinux user identities"> -# <i>semanage user -l</i> -SELinux User SELinux Roles - -root staff_r sysadm_r -sophie staff_r sysadm_r -staff_u staff_r sysadm_r -sysadm_u sysadm_r -system_u system_r -unconfined_u unconfined_r -user_u user_r - -# <i>semanage login -l</i> -Login Name SELinux User - -__default__ user_u -root root -sophie staff_u -swift staff_u -system_u system_u -</pre> - -<p> -Now that a new SELinux user called "sophie" exists, we can now update the Linux -user mapping for "sophie" towards the new SELinux user "sophie": -</p> - -<pre caption="Updating the Linux user mapping"> -# <i>semanage login -m -s sophie sophie</i> -# <i>semanage login -l</i> -Login Name SELinux User - -__default__ user_u -root root -sophie sophie -swift staff_u -system_u system_u -</pre> - -<p> -Again, do not forget to relabel this users' files. -</p> - -<p> -As you can see, managing SELinux users means defining the roles to which the -user has access to. We already gave a high-level introduction to the default -roles in <uri link="?part=1&chap=2">SELinux Concepts</uri>, but as roles are -important when using a Mandatory Access Control system, let's refresh our memory -again: -</p> - -<table> -<tr> - <th>SELinux Role</th> - <th>Description</th> -</tr> -<tr> - <ti>user_r</ti> - <ti> - Default end-user role. This role provides access to regular applications and - activities, but does not allow any system or service administration beyond - what is expected for a regular user. - </ti> -</tr> -<tr> - <ti>staff_r</ti> - <ti> - Default administration role for day-to-day activities. This role has some - additional privileges beyond what is offered through user_r, but is not a - full system administrative role. It is meant for the non-administrative - activities done by operators and administrators - </ti> -</tr> -<tr> - <ti>sysadm_r</ti> - <ti> - System administration role. This role is highly privileged (since it also - contains the privileges to update the policy) and should only be given to - fully trusted administrators. It is almost never immediately granted to - users (they first need to switch roles) except for direct root access (for - instance through the console) - </ti> -</tr> -<tr> - <ti>system_r</ti> - <ti> - System service role, which is used for the runtime services (processes). It - is never granted to users directly. - </ti> -</tr> -<tr> - <ti>unconfined_r</ti> - <ti> - The unconfined role is used when the <e>targeted</e> policy is supported. - This role is given to unconfined users (such as the SELinux unconfined_u - user) which have very wide privileges (they almost run without constraints). - </ti> -</tr> -</table> - -<p> -It should be noted that these roles are the default ones, but the security -administrator - yes, that means you - can create additional roles and add -particular privileges to it. We will discuss this later in this book as it means -you'll need to update the Gentoo Hardened SELinux policy. -</p> - -</body> -</subsection> -</section> - -<section> -<title>Reading Audit Logs</title> -<subsection> -<title>Introduction</title> -<body> - -<p> -When working with a SELinux-enabled system, you will eventually notice that -things behave differently, but without giving any meaningful error message. -Usually, when SELinux "denies" a particular access, it logs it into the audit -log of the system, but for the application itself, it is perfectly possible that -it just silently dies. If not, you're most likely to get a <e>permission -denied</e> error message. -</p> - -<p> -Initially, SELinux is running in <c>permissive</c> mode, which means that -SELinux will log what it <e>would</e> deny, but still let it through. -This mode is perfect for getting the system in shape without having too -much problems keeping it running. Once you think your security settings are -in order, then this mode can be switched from <c>permissive</c> to -<c>enforcing</c>. We'll talk about these modes later. -</p> - -<p> -First, let's take a look at the audit log and see what it is saying... -</p> - -</body> -</subsection> -<subsection> -<title>Audit Log Location(s)</title> -<body> - -<p> -The SELinux kernel code writes its denials (and sometimes even allowed but -audited activities) into the audit log. If you are running on a Gentoo Hardened -installation with the <c>syslog-ng</c> system logger, then the logger is already -configured to place these audit lines in <path>/var/log/avc.log</path>. However, -different system loggers or system logger configurations might put the entries -in a different log location (such as <path>/var/log/audit.log</path>). -</p> - -<p> -Below, you'll find the appropriate lines for the syslog-ng system logger -configuration for writing the events in <path>/var/log/avc.log</path>. -</p> - -<pre caption="syslog-ng.conf excerpt for SELinux AVC entries"> -<comment># The following lines are only /part/ of the configuration file!</comment> -source kernsrc { file("/proc/kmsg"); }; -destination avc { file("/var/log/avc.log"); }; -filter f_avc { message(".*avc: .*"); }; - -log { - source(kernsrc); - filter(f_avc); - destination(avc); -}; -</pre> - -</body> -</subsection> -<subsection> -<title>What is AVC?</title> -<body> - -<p> -As we mentioned, SELinux writes its entries in the audit log. These entries are -called <e>avc messages</e> or <e>avc log entries</e>. The abbreviation AVC -stands for <e>Access Vector Cache</e> and, like the name sais, is a caching -system. -</p> - -<p> -Using an access vector cache improves performance on dealing with (and -enforcing) activities and privileges. Since SELinux offers a very detailed -approach on privileges and permissions, it would become quite painful -(performance-wise) if each call means that the SELinux code needs to look up the -domain, the target resource label, the privilege and if it is allowed or not -over and over again. Instead, SELinux uses the Access Vector Cache to store past -requests/responses. It is the AVC subsystem that is responsible for checking -accesses and (if necessary) logging it. -</p> - -</body> -</subsection> -<subsection> -<title>Reading an AVC Denial Message</title> -<body> - -<p> -Below you'll find a typical AVC denial message. -</p> - -<pre caption="Example AVC denial message"> -Oct 15 13:04:54 hpl kernel: [963185.177043] type=1400 audit(1318676694.660:2472): - avc: denied { module_request } for pid=14561 comm="firefox" kmod="net-pf-10" - scontext=staff_u:staff_r:mozilla_t tcontext=system_u:system_r:kernel_t tclass=system -</pre> - -<p> -Let's analyze each part of this message one by one. -</p> - -<pre caption="AVC denial: Timestamp and location information"> -<i>Oct 15 13:04:54 hpl kernel: [963185.177043]</i> type=1400 audit(1318676694.660:2472): - avc: denied { module_request } for pid=14561 comm="firefox" kmod="net-pf-10" - scontext=staff_u:staff_r:mozilla_t tcontext=system_u:system_r:kernel_t tclass=system -</pre> - -<p> -This first part of the message informs you when the message was written (Oct 15 -13:04:54), on which host (hpl) and how many seconds since the system was booted -(963185.177043). -</p> - -<pre caption="AVC denial: source information"> -Oct 15 13:04:54 hpl kernel: [963185.177043] type=1400 audit(1318676694.660:2472): - avc: denied { module_request } for <i>pid=14561 comm="firefox"</i> kmod="net-pf-10" - <i>scontext=staff_u:staff_r:mozilla_t</i> tcontext=system_u:system_r:kernel_t tclass=system -</pre> - -<p> -Next is the source of the denial, i.e. what process is trying to do something. -In this case, the process is firefox, with PID 14561, which is running in the -source domain staff_u:staff_r:mozilla_t. -</p> - -<pre caption="AVC denial: target resource"> -Oct 15 13:04:54 hpl kernel: [963185.177043] type=1400 audit(1318676694.660:2472): - avc: denied { module_request } for pid=14561 comm="firefox" <i>kmod="net-pf-10"</i> - scontext=staff_u:staff_r:mozilla_t <i>tcontext=system_u:system_r:kernel_t</i> tclass=system -</pre> - -<p> -The target of the activity is a kernel module (net-pf-10, which is the internal -name given for IPv6), labeled system_u:system_r:kernel_t -</p> - -<pre caption="AVC denial: denied action"> -Oct 15 13:04:54 hpl kernel: [963185.177043] type=1400 audit(1318676694.660:2472): - avc: denied { <i>module_request</i> } for pid=14561 comm="firefox" kmod="net-pf-10" - scontext=staff_u:staff_r:mozilla_t tcontext=system_u:system_r:kernel_t <i>tclass=system</i> -</pre> - -<p> -Finally, the action that is denied (module_request) and its class (system). -These classes help you to identify what is denied, because a read on a file is -different from a read on a directory. -</p> - -<p> -For instance, in the following case, a process <c>gorg</c> with PID 13935 is -trying to read a file called <path>localtime</path> with inode 130867 which -resides on the device <path>/dev/md3</path>: -</p> - -<pre caption="AVC denial example"> -Oct 15 14:40:30 hpl kernel: [968909.807802] type=1400 audit(1318682430.323:2614): - avc: denied { read } for pid=13935 comm="gorg" name="localtime" dev=md3 ino=130867 - scontext=staff_u:sysadm_r:gorg_t tcontext=system_u:object_r:locale_t tclass=file -</pre> - -<p> -In this case, it might be obvious that the file is <path>/etc/localtime</path>, -but when that isn't the case, then you can find the following two commands -useful: -</p> - -<pre caption="Finding out the target resource based on inode and device"> -<comment>(Find out which device /dev/md3 is)</comment> -# <i>mount | grep /dev/md3</i> -/dev/md3 on / type ext4 (rw,seclabel,noatime,barrier=1,nodelalloc,data=journal) - -<comment>(Find out what file has inode 130867)</comment> -# <i>find / -xdev -inum 130867</i> -/etc/localtime -</pre> - -</body> -</subsection> -<subsection> -<title>Handling AVC denials</title> -<body> - -<p> -The major part of configuring SELinux is reading the denials, finding out what -needs to be fixed (or ignored), fix it, and repeat the steps. Hopefully, the -rest of this handbook will help you figure out what is causing a denial. -</p> - -<p> -Denials can be cosmetic (an activity that is denied, but has no effect on the -application's functional behaviour). If that is the case, the denial can be -marked as <e>dontaudit</e>, meaning that the denial is not logged by default -anymore. If you think that a denial is occurring but you do not see it in the -logs, try disabling the <e>dontaudit</e> rules: -</p> - -<pre caption="Disabling dontaudit"> -<comment>(The command can also be abbreviated to "semodule -DB")</comment> -# <i>semodule --build --disable_dontaudit</i> -</pre> - -<p> -In most cases though, denials need to be acted upon. Actions that might need to -happen are: -</p> - -<ul> - <li> - relabeling the target resource (wrong labels might cause legitimate actions - to be denied) - </li> - <li> - relabeling the source (process' binary file) as a wrong label might cause - the application to run in the wrong domain - </li> - <li> - loading a necessary SELinux module, since the modules contain the rules to - allow (and label) resources. Without the appropriate module loaded, you will - notice denials since no other module gives the necessary grants (allow - statements) - </li> - <li> - granting the right role to the user executing the application. We have - covered users and their roles initially but we will go deeper into this - subject later in the handbook. - </li> - <li> - adding your own SELinux policy statements, most likely because no SELinux - policy module exists for the application you are trying to run - </li> -</ul> - -</body> -</subsection> -</section> - -<section> -<title>Using (File) Labels</title> -<subsection> -<title>Introduction</title> -<body> - -<p> -Within SELinux, access privileges are based on the label given on the -originating part (called the <e>domain</e>) and its target resource. For -instance, a process running in the passwd_t domain wants to read (= privilege) -the file <path>/etc/shadow</path> which is labeled shadow_t (= the target -resource). It comes to no surprise then that the majority of SELinux -administration is (re)labeling the resources correctly (and ensuring their label -stays correct). -</p> - -</body> -</subsection> -<subsection> -<title>Getting File Label(s)</title> -<body> - -<p> -There are many ways to relabel commands, and none of them are equal to another. -But before we explain this in more detail, let's first take a look at a few file -labels (and how you can query them). -</p> - -<p> -In SELinux, labels are given on a file level through the file systems' ability -to keep <e>extended attributes</e>. For SELinux, the attribute is called -<c>security.selinux</c> and can be obtained through <c>getfattr</c>: -</p> - -<pre caption="Getting a file's extended attribute for SELinux"> -$ <i>getfattr -n security.selinux /etc/hosts</i> -# file: etc/hosts -security.selinux="system_u:object_r:net_conf_t" -</pre> - -<p> -Of course, getting the file attribute this way is time consuming and not that -flexible. For this purpose, most important applications (including -<c>coreutils</c>) are made SELinux-aware. These applications mostly use the -<c>-Z</c> option to display the SELinux context information. In case of files, -this means the extended attribute content: -</p> - -<pre caption="Getting the context of a file"> -$ <i>ls -Z /etc/hosts</i> -system_u:object_r:net_conf_t /etc/hosts -</pre> - -<p> -Other commands exist that display the context as it should be, like -<c>matchpathcon</c>. However, their purpose is to query the SELinux policy on -your system to find out what the policy ought to be, not what it is: -</p> - -<pre caption="Difference between context and matchpathcon result"> -$ <i>ls -Z /etc/make.conf</i> -staff_u:object_r:etc_t /etc/make.conf -$ <i>matchpathcon /etc/make.conf</i> -/etc/make.conf system_u:object_r:portage_conf_t -</pre> - -</body> -</subsection> -<subsection> -<title>Setting File Label(s)</title> -<body> - -<p> -Now how can you manipulate file labels? Well, first of all: you will not be -allowed to change the file labels of any possible file (not even if you are the -owner of that file) unless the SELinux policy allows you to. These allow rules -are made on two privilege types: which labels are you allowed to change -(<c>relabelfrom</c>) and to which labels are you allowed to change -(<c>relabelto</c>). You can query these rules through <c>sesearch</c>: -</p> - -<pre caption="Querying the relabelto/relabelfrom types"> -<comment># From which label on files (-c) is user_t (-s) allowed (-A) to relabel from (-p)?</comment> -$ <i>sesearch -s user_t -c file -p relabelfrom -A</i> -<comment>[...]</comment> -allow user_t mozilla_home_t : file { <comment>...</comment> relabelfrom relabelto } ; -</pre> - -<p> -If you have the permission, then you can use <c>chcon</c> to <e>ch</e>ange the -<e>con</e>text of a file: -</p> - -<pre caption="Changing a file context"> -$ <i>ls -Z strace.log</i> -staff_u:object_r:user_home_t strace.log -$ <i>chcon -t mutt_home_t strace.log</i> -$ <i>ls -Z strace.log</i> -staff_u:object_r:mutt_home_t strace.log -</pre> - -<p> -If you do not hold the right privileges, you will get a descriptive error -message: -</p> - -<pre caption="Trying to change file context"> -$ <i>chcon -t shadow_t strace.log</i> -chcon: failed to change context of `strace.log' to `staff_u:object_r:shadow_t': Permission denied -</pre> - -<p> -Now, if you now think that <c>chcon</c> is all you need, you're wrong. The -<c>chcon</c> command does nothing more than what it sais - change context. But -when the system relabels files, these changes are gone. Relabeling files is -often done to ensure that the file labels are correct (as in: the labels match -what the SELinux policy sais they ought to be). The SELinux policy contains, for -each policy module, the list of files, directories, sockets, ... and their -appropriate file context (label). -</p> - -<p> -We will look at SELinux policy modules later, but below you'll find an excerpt -from such a definition, for the <c>mozilla</c> module: -</p> - -<pre caption="Excerpt of the mozilla module file contexts"> -/usr/bin/firefox-bin -- gen_context(system_u:object_r:mozilla_exec_t,s0) -/usr/bin/mozilla-[0-9].* -- gen_context(system_u:object_r:mozilla_exec_t,s0) -/usr/bin/mozilla-bin-[0-9].* -- gen_context(system_u:object_r:mozilla_exec_t,s0) -/usr/lib(64)?/galeon/galeon -- gen_context(system_u:object_r:mozilla_exec_t,s0) -/usr/lib(64)?/netscape/.+/communicator/communicator-smotif\.real -- gen_context(system_u:object_r:mozilla_exec_t,s0) -/usr/lib(64)?/netscape/base-4/wrapper -- gen_context(system_u:object_r:mozilla_exec_t,s0) -/usr/lib/[^/]*firefox[^/]*/plugin-container -- gen_context(system_u:object_r:mozilla_plugin_exec_t,s0) -/usr/lib64/[^/]*firefox[^/]*/plugin-container -- gen_context(system_u:object_r:mozilla_plugin_exec_t,s0) -</pre> - -<p> -To put the right label on a file, you can use the <c>setfiles</c> or -<c>restorecon</c> commands. Since they are both the same command (but with a -slightly different way of using) we'll only talk about <c>restorecon</c> for now -- more information on the <c>setfiles</c> command can be found in its man page. -</p> - -<p> -When you use <c>restorecon</c>, the application will query the SELinux policy to -find out what the right label of the file should be. If it differs, it will -change the label to the right setting. That means that you do not need to -provide the label for a file in order for the command to work. Also, -<c>restorecon</c> supports recursivity, so you do not need to relabel files one -by one. -</p> - -<pre caption="Using restorecon"> -$ <i>ls -Z /etc/make.conf</i> -staff_u:object_r:etc_t /etc/make.conf -$ <i>restorecon /etc/make.conf</i> -$ <i>ls -Z /etc/make.conf</i> -system_u:object_r:portage_conf_t /etc/make.conf -</pre> - -<p> -Finally, Gentoo also provides a useful application: <c>rlpkg</c>. This script -relabels the files of a Gentoo package (<c>rlpkg <packagename></c>) or, -given the right arguments, all files on the file system: -</p> - -<pre caption="Using rlpkg"> -<comment># Relabel the files of the firefox-bin package:</comment> -# <i>rlpkg firefox</i> - -<comment># Relabel all files on the file system:</comment> -# <i>rlpkg -a -r</i> -</pre> - -</body> -</subsection> -<subsection> -<title>Overriding the SELinux Policy File Labels</title> -<body> - -<p> -You might not always agree with the label that the SELinux policy enforces on -the files: you might have your files located elsewhere (a different location for -your Portage tree is a nice example) or you need to label them differently in -order for other applications to work. To not have to <c>chcon</c> these files -over and over again, you can enhance the SELinux policy on your system with -additional file context rules. These rules are used when you call -<c>restorecon</c> as well and override the rules provided by the SELinux policy. -</p> - -<p> -To add additional file context rules, you need to use the <c>semanage</c> -command. This command is used to manage, manipulate and update the local SELinux -policy on your system. In this particular case, we will use the <c>semanage -fcontext</c> command: -</p> - -<pre caption="Using semanage to add a file context rule"> -<comment># Mark /mnt/gentoo/etc/make.conf as a portage_conf_t type</comment> -# <i>semanage fcontext -a -t portage_conf_t /mnt/gentoo/etc/make.conf</i> - -<comment># Mark /mnt/gentoo/usr/portage as portage_ebuild_t</comment> -# <i>semanage fcontext -a -t portage_ebuild_t "/mnt/gentoo/usr/portage(/.*)?"</i> -</pre> - -<p> -As you can see from the example, you can use wildcards. But beware about using -wildcards: when a rule holds a wildcard, it has a lower priority than a rule -without a wildcard. And the priority on rules with a wildcard is based on how -"down" the string the first occurance of a wildcard is. For more information, -please check out our <uri link="../selinux-faq.xml#matchcontext">FAQ on "How do -I know which file context rule is used for a particular file?."</uri> -</p> - -<p> -If you want to delete a file context definition, you use <c>semanage fcontext --d</c>: -</p> - -<pre caption="Deleting a file context definition"> -# <i>semanage fcontext -d -t portage_ebuild_t /mnt/gentoo/etc/make.conf</i> -</pre> - -<p> -Finally, to view all file context definitions (both user-set and SELinux policy -provided), you can use <c>semanage fcontext -l</c>. To only see the locally set, -add <c>-C</c>: -</p> - -<pre caption="Viewing user-set file context enhancements"> -# <i>semanage fcontext -C -l</i> -SELinux fcontext type Context -/opt/xxe/bin/.*\.jar all files system_u:object_r:lib_t -/srv/virt/gentoo(/.*)? all files system_u:object_r:qemu_image_t -</pre> - -</body> -</subsection> -<subsection> -<title>Customizable types</title> -<body> - -<p> -Labels on files are not that hard to understand, but you might come into some -surprises if you do not know that there are also customizable types. -</p> - -<p> -A <e>customizable type</e> is a specific type which is not touched by the -SELinux administration tools by default. If you want to relabel a file that -currently holds a customizable type, you will need to force this through the -commands (such as <c>restorecon -F</c>). -</p> - -<p> -There are not that many customizable types by default. The list of types that -SELinux considers as customizable are mentioned in the -<path>customizable_types</path> file within the -<path>/etc/selinux/*/contexts</path> location: -</p> - -<pre caption="Listing the customizable types"> -# <i>cat /etc/selinux/strict/contexts/customizable_types</i> -mount_loopback_t -public_content_rw_t -public_content_t -swapfile_t -textrel_shlib_t -</pre> - -<p> -Such types exist because these types are used for files whose location is known -not to be fixed (and as such, the SELinux policy cannot without a doubt know if -the label on the files is correct or not). The <c>public_content_t</c> one, -which is used for files that are readable by several services (like FTP, web -server, ...), might give you a nice example for such a case. -</p> - -<p> -If you look at the <c>restorecon</c> man page, it mentions both customizable -types as well as the user section. The latter is for rules that are identified -in the SELinux policy as being files for an end user, like the following -definitions in the <c>mozilla</c> policy module: -</p> - -<pre caption="User section definition within mozilla module"> -HOME_DIR/\.mozilla(/.*)? gen_context(system_u:object_r:mozilla_home_t,s0) -HOME_DIR/\.netscape(/.*)? gen_context(system_u:object_r:mozilla_home_t,s0) -HOME_DIR/\.phoenix(/.*)? gen_context(system_u:object_r:mozilla_home_t,s0) -</pre> - -<p> -Although in the above example, forcing <c>restorecon</c> on the files is -probably correct, there are examples where you do not want this. For instance, -the firefox policy by default only allows the application to write to -directories labeled <c>mozilla_home_t</c>. If you want to download something, -this isn't possible (unless you download it into <path>~/.mozilla</path>). The -solution there is to label a directory (say <path>~/Downloads</path>) as -<c>mozilla_home_t</c>. -</p> - -</body> -</subsection> -</section> - -<section> -<title>SELinux Policy and Booleans</title> -<subsection> -<title>Introduction</title> -<body> - -<p> -We have dealt with users and labels now, but there is still a third aspect that -we haven't touched: the SELinux policy itself. -</p> - -<p> -The SELinux policy as offered by Gentoo Hardened is a carefully tuned SELinux -policy, based on the reference policy (a distribution-agnostic SELinux policy) -with minor changes. Hopefully, you will not need to rewrite the policy to suit -it for your needs, but changes are very likely to occur here and there. -</p> - -</body> -</subsection> -<subsection> -<title>Changing the SELinux Policy Behavior: Booleans</title> -<body> - -<p> -A common and user friendly way of tweaking the SELinux policy is through -booleans. A <e>SELinux boolean</e>, also known as a conditional, changes how the -SELinux policy behaves based on the setting that the user provides. To make this -a bit more clear, let's look at a few booleans available: -</p> - -<pre caption="Getting SELinux booleans"> -# <i>getsebool -a | grep ^user</i> -user_direct_mouse --> off -user_dmesg --> off -user_ping --> on -user_rw_noexattrfile --> off -user_tcp_server --> off -user_ttyfile_stat --> off -</pre> - -<p> -Although they might not say much on first sight, these booleans alter how the -SELinux policy enforces user activity (hence the booleans starting with -<path>user_</path>). For instance, <c>user_ping</c> is set to <c>on</c>, so a -user is allowed to use <c>ping</c>. If it was set to <c>off</c>, the SELinux -policy would not allow a user to execute <c>ping</c>. -</p> - -<p> -Booleans can be toggled on or off using <c>setsebool</c> or <c>togglesebool</c>. -With <c>setsebool</c> you need to give the value (on or off) whereas -<c>togglesebool</c> switches the value. -</p> - -<pre caption="Disallowing the use of ping by users"> -# <i>setsebool user_ping off</i> -</pre> - -<p> -By default, <c>setsebool</c> does not store the boolean values - after a reboot, -the old values are used again. To persist such changes, you need to add the -<c>-P</c> option: -</p> - -<pre caption="Persistedly allow users to run dmesg"> -# <i>setsebool -P user_dmesg on</i> -</pre> - -<p> -Booleans allow administrators to tune the policy, and allow security -administrators to write policies that are flexible enough for a more widespread -use. In terms of Gentoo flexibility, these booleans might not be used enough (it -would be nice to couple these booleans on USE flags, so that a server build with -USE="ldap" gets the SELinux policy to use ldap, whereas USE="-ldap" disallows -it). But still, the use of booleans is a popular method for making a more -flexible SELinux policy. -</p> - -</body> -</subsection> -<subsection> -<title>Managing SELinux Policy Modules</title> -<body> - -<p> -In this last part, we'll cover SELinux policy modules. We mentioned before that -the SELinux policy used by Gentoo Hardened is based on the reference policy, -which offers a modular approach to SELinux policies. There is one base policy, -which is mandatory on every system and is kept as small as possible. The rest -are SELinux policy modules, usually providing the declarations, rules and file -contexts for a single application (or type of applications). -</p> - -<p> -With <c>semodule -l</c> you can see the list of SELinux policy modules loaded: -</p> - -<pre caption="Listing the loaded SELinux modules"> -# <i>semodule -l</i> -alsa 1.11.0 -apache 2.3.0 -entropyd 1.6.0 -dbus 1.15.0 -dnsmasq 1.9.0 -<comment>(...)</comment> -</pre> - -<p> -Within Gentoo Hardened, each module is provided by the package -<path>sec-policy/selinux-<modulename></path>. For instance, the first -module encountered in the above example is provided by -<path>selinux-alsa</path>: -</p> - -<pre caption="The SELinux policy module package in Gentoo"> -$ <i>emerge --search selinux-alsa</i> -Searching... -[ Results for search key : selinux-alsa ] -[ Applications found : 1] - -* sec-policy/selinux-alsa - Latest version available: 2.20110726 - Latest version installed: 2.20110726 - Size of files: 574 kB - Homepage: http://www.gentoo.org/proj/en/hardened/selinux/ - Description: SELinux policy for alsa - License: GPL-2 -</pre> - -<p> -If you need a module that isn't installed on your system, this is considered a -bug (packages that need it should depend on the SELinux policy package if the -selinux USE flag is set). But once you install the package yourself, the module -will be loaded automatically: -</p> - -<pre caption="Installing a SELinux policy package"> -# <i>emerge selinux-screen</i> -</pre> - -<p> -If you want to remove a module from your system though, uninstalling the package -will not suffice: the SELinux policy module itself is copied to the policy store -earlier (as part of the installation process) and is not removed from this store -by Portage. Instead, you will need to remove the module manually: -</p> - -<pre caption="Uninstalling a SELinux policy module"> -# <i>emerge -C selinux-screen</i> -# <i>semodule -r screen</i> -</pre> - -</body> -</subsection> -</section> -</sections> diff --git a/xml/selinux/hb-using-install.xml b/xml/selinux/hb-using-install.xml deleted file mode 100644 index 672f11d..0000000 --- a/xml/selinux/hb-using-install.xml +++ /dev/null @@ -1,741 +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-using-install.xml,v 1.4 2011/06/07 19:46:52 klondike Exp $ --> - -<sections> -<version>24</version> -<date>2012-05-07</date> - -<section> -<title>Installing Gentoo (Hardened)</title> -<subsection> -<title>Introduction</title> -<body> - -<p> -Getting a SELinux-powered Gentoo installation doesn't require weird actions. -What you need to do is install Gentoo Linux with the correct profile, correct -kernel configuration and some file system relabelling. We seriously recommend to -use SELinux together with other hardening improvements (such as PaX / -grSecurity). -</p> - -<p> -This chapter will describe the steps to install Gentoo with SELinux. We -assume that you have an existing Gentoo Linux system which you want to convert -to Gentoo with SELinux. If this is not the case, you should still read -on: you can install Gentoo with SELinux immediately if you make the -correct decisions during the installation process, based on the information in -this chapter. -</p> - -</body> -</subsection> -<subsection> -<title>Performing a Standard Installation</title> -<body> - -<p> -Install Gentoo Linux according to the <uri link="/doc/en/handbook">Gentoo -Handbook</uri> installation instructions. We recommend the use of the hardened -stage 3 tarballs and <c>hardened-sources</c> kernel instead of the standard -ones, but standard stage installations are also supported for SELinux. -Perform a full installation to the point that you have booted your system -into a (primitive) Gentoo base installation. -</p> - -<note> -If you are an XFS user, make sure that the inode sizes of the XFS file -system is 512 byte. Since the default is 256, you will need to run the -<c>mkfs.xfs</c> command with the <c>-i size=512</c> arguments, like so: -<c>mkfs.xfs -i size=512 /dev/sda3</c> -</note> - -</body> -</subsection> -<!-- -<subsection> -<title>Installing the Hardened Development Overlay</title> -<body> - -<p> -Although optional, we recommend to enable the <c>hardened-development</c> -overlay. The state of SELinux within Gentoo Hardened is still undergoing -major development. -</p> - -<p> -Install <c>app-portage/layman</c> and add the <c>hardened-development</c> -overlay. This overlay uses a git repository, so either install <c>git</c> as -well, or set <c>USE="git"</c> in <path>/etc/make.conf</path>. -Make sure to include layman's <path>make.conf</path> in your -<path>make.conf</path> file. -</p> - -<pre caption="Installing hardened-development overlay"> -~# <i>emerge layman</i> - -~# <i>layman -S</i> - -~# <i>layman -a hardened-development</i> - -~# <i>nano /etc/make.conf</i> -<comment># Add the following line at the top of your make.conf file</comment> -<i>source /var/lib/layman/make.conf</i> -</pre> - -</body> -</subsection> ---> -<!-- -TODO Validate after 2.20120215-r8 is stable that this is no longer -necessary? Not sure about it though : check userspace ebuilds as well. ---> -<subsection> -<title>Switching to Python 2</title> -<body> - -<p> -For now, the SELinux management utilities are not compatible with Python 3 so -we recommend to switch to Python 2 until the packages are updated and fixed. -</p> - -<pre caption="Switching to python 2"> -~# <i>emerge '<=dev-lang/python-3.0'</i> -~# <i>eselect python list</i> -Available Python interpreters: - [1] python2.7 - [2] python3.1 * - -~# <i>eselect python set 1</i> -~# <i>source /etc/profile</i> -</pre> - -</body> -</subsection> -<subsection> -<title>Optional: Setting the filesystem contexts</title> -<body> - -<p> -If your <path>/tmp</path> location is a tmpfs-mounted file system, then you need -to tell the kernel that the root context of this location is <c>tmp_t</c> -instead of <c>tmpfs_t</c>. Many SELinux policy objects (including various -server-level policies) assume that <path>/tmp</path> is <c>tmp_t</c>. -</p> - -<p> -To configure the <path>/tmp</path> mount, edit your <path>/etc/fstab</path>: -</p> - -<pre caption="Update /etc/fstab for /tmp"> -<comment># For a "targeted" or "strict" policy type:</comment> -tmpfs /tmp tmpfs defaults,noexec,nosuid<i>,rootcontext=system_u:object_r:tmp_t</i> 0 0 - -<comment># For an "mls" or "mcs" policy type:</comment> -tmpfs /tmp tmpfs defaults,noexec,nosuid<i>,rootcontext=system_u:object_r:tmp_t:s0</i> 0 0 -</pre> - -</body> -</subsection> -<!-- -<subsection> -<title>Enabling ~Arch Packages</title> -<body> - -<p> -The current stable SELinux related packages are not fit for use anymore (or are -even broken) so we seriously recommend to enable ~arch packages for SELinux. Add -the following settings to the right file (for instance -<path>/etc/portage/package.accept_keywords/selinux</path>): -</p> - -<pre caption="SELinux ~arch packages"> -=sys-process/vixie-cron-4.1-r11 -</pre> - -</body> -</subsection> ---> -<subsection> -<title>Change the Gentoo Profile</title> -<body> - -<p> -Now that you have a running Gentoo Linux installation, switch the Gentoo profile -to the right SELinux profile (for instance, -<path>hardened/linux/amd64/no-multilib/selinux</path>). Note that the older -profiles (like <path>selinux/v2refpolicy/amd64/hardened</path>) are not -supported anymore. -</p> - -<pre caption="Switching the Gentoo profile"> -~# <i>eselect profile list</i> -Available profile symlink targets: - [1] default/linux/amd64/10.0 - [2] default/linux/amd64/10.0/selinux - [3] default/linux/amd64/10.0/desktop - [4] default/linux/amd64/10.0/desktop/gnome - [5] default/linux/amd64/10.0/desktop/kde - [6] default/linux/amd64/10.0/developer - [7] default/linux/amd64/10.0/no-multilib - [8] default/linux/amd64/10.0/server - [9] hardened/linux/amd64 - [10] hardened/linux/amd64/selinux - [11] hardened/linux/amd64/no-multilib * - [12] hardened/linux/amd64/no-multilib/selinux - -~# <i>eselect profile set 12</i> -</pre> - -<note> -Starting from the profile change, Portage will warn you after every installation -that it was "Unable to set SELinux security labels". This is to be expected, -because the tools and capabilities that Portage requires to set the security -labels aren't available yet. This warning will vanish the moment the SELinux -installation is completed. -</note> - -<p> -Don't update your system yet - we will need to install a couple of packages in a -particular order which Portage isn't aware of in the next couple of sections. -</p> - -</body> -</subsection> -<subsection> -<title>Update make.conf</title> -<body> - -<p> -Next, take a look at the following USE flags and decide if you want to enable -or disable them. -</p> - -<table> -<tr> - <th>USE flag</th> - <th>Default Value</th> - <th>Description</th> -</tr> -<tr> - <ti>peer_perms</ti> - <ti>Enabled</ti> - <ti> - The peer_perms capability controls the SELinux policy network peer controls. - If set, the access control mechanisms that SELinux uses for network based - labelling are consolidated. This setting is recommended as the policy is - also updated to reflect this. If not set, the old mechanisms (NetLabel and - Labeled IPsec) are used side by side. - </ti> -</tr> -<tr> - <ti>open_perms</ti> - <ti>Enabled</ti> - <ti> - The open_perms capability enables the SELinux permission "open" for files - and file-related classes. Support for the "open" call was added a bit later - than others so support was first made optional. However, the policies have - matured sufficiently to have the open permission set. - </ti> -</tr> -<tr> - <ti>ubac</ti> - <ti>Enabled</ti> - <ti> - When disabled, the SELinux policy is built without user-based access control. - </ti> -</tr> -</table> - -<p> -Make your choice and update the <c>USE</c> variable in -<path>/etc/make.conf</path>. -</p> - -</body> -</subsection> -<subsection> -<title>Manual System Changes</title> -<body> - -<warn> -Most, if not all of the next few changes will be resolved through regular -packages as soon as possible. However, these fixes have impact beyond the Gentoo -Hardened installations. As such, these changes will be incorporated a bit slower -than the SELinux-specific updates. For the time being, manually correcting these -situations is sufficient (and a one-time operation). -</warn> - -<p> -The following changes <e>might</e> be necessary on your system, depending on the -tools or configurations that apply. -</p> - -<ul> - <li> - Check if you have <path>*.old</path> files in <path>/bin</path>. If you do, - either remove those or make them a copy of their counterpart so that they - get their own security context. The <path>.old</path> files are hard links - which mess up the file labelling. For instance, <c>cp /bin/hostname - /bin/hostname.old</c>. - </li> - <!-- - TODO When portage fix is stabilized, convert docs to /sys/fs/selinux - --> - <li> - Edit <path>/etc/sandbox.conf</path> and add in - <c>SANDBOX_WRITE="/sys/fs/selinux/context"</c>. This is temporarily needed - until the necessary fix (included in Portage but not stable yet) is - available. - </li> -</ul> - -</body> -</subsection> -<subsection> -<title>Installing a SELinux Kernel</title> -<body> - -<p> -Although the default Linux kernels offer SELinux support, we recommend the use -of the <path>sys-kernel/hardened-sources</path> package. -</p> - -<pre caption="Installing hardened-sources"> -<comment>(Only if you have not installed it previously of course)</comment> -~# <i>emerge hardened-sources</i> -</pre> - -<p> -Next, reconfigure the kernel with the appropriate security settings. This -includes, but is not limited to -</p> - -<ul> - <li>Support for extended attributes in the various file systems</li> - <li>Support system-call auditing</li> - <li>Support for SELinux</li> -</ul> - -<p> -Below you can find a quick overview of the recommended settings. -</p> - -<pre caption="Recommended settings for the Linux kernel configuration"> -<comment>Under "General setup"</comment> -[*] Prompt for development and/or incomplete code/drivers -[*] Auditing support -[*] Enable system-call auditing support - -<comment>Under "File systems"</comment> -<comment>(For each file system you use, make sure extended attribute support is enabled)</comment> -<*> Second extended fs support -[*] Ext2 extended attributes -[ ] Ext2 POSIX Access Control Lists -[*] Ext2 Security Labels -[ ] Ext2 execute in place support - -<*> Ext3 journalling file system support -[ ] Default to 'data=ordered' in ext3 -[*] Ext3 extended attributes -[ ] Ext3 POSIX Access Control Lists -[*] Ext3 Security Labels - -<*> The Extended 4 (ext4) filesystem -[*] Ext4 extended attributes -[ ] Ext4 POSIX Access Control Lists -[*] Ext4 Security Labels - -<*> JFS filesystem support -[ ] JFS POSIX Access Control Lists -[*] JFS Security Labels -[ ] JFS debugging -[ ] JFS statistics - -<*> XFS filesystem support -[ ] XFS Quota support -[ ] XFS POSIX ACL support -[ ] XFS Realtime subvolume support (EXPERIMENTAL) -[ ] XFS Debugging Support - -<*> Btrfs filesystem (EXPERIMENTAL) -[ ] Btrfs POSIX Access Control Lists - -<comment>Under "Security options"</comment> -[*] Enable different security models -[*] Socket and Networking Security Hooks -[*] NSA SELinux Support -[ ] NSA SELinux boot parameter -[ ] NSA SELinux runtime disable -[*] NSA SELinux Development Support -[ ] NSA SELinux AVC Statistics -(1) NSA SELinux checkreqprot default value -[ ] NSA SELinux maximum supported policy format version - Default security module (SELinux) ---> -</pre> - -<p> -We recommend to use PaX as well. More information on PaX within Gentoo Hardened -can be found in the <uri link="/proj/en/hardened/pax-quickstart.xml">Hardened -Gentoo PaX Quickstart Guide</uri>. -</p> - -<p> -Build and install the new Linux kernel and its modules. -</p> - -</body> -</subsection> -<subsection> -<title>Update fstab</title> -<body> - -<p> -Next, edit <path>/etc/fstab</path> and add the following two lines: -</p> - -<pre caption="Enabling selinux-specific file system options"> -<comment># The udev mount is due to bug #373381</comment> -udev /dev tmpfs rw,rootcontext=system_u:object_r:device_t,seclabel,nosuid,relatime,size=10m,mode=755 0 0 -none /selinux selinuxfs defaults 0 0 -</pre> - -<note> -In case of an MLS/MCS policy, you need to have the context with sensitivity -level, so <c>...:device_t:s0</c>. -</note> - -</body> -</subsection> -<subsection> -<title>Reboot</title> -<body> - -<p> -With the above changes made, reboot your system. Assert yourself that you are -now running a Linux kernel with SELinux enabled (the <path>/selinux</path> file -system should be mounted). Don't worry - SELinux is at this point not activated. -</p> - -</body> -</subsection> -</section> - -<section> -<title>Configure SELinux</title> -<subsection> -<title>Introduction</title> -<body> - -<p> -Next we will need to configure SELinux by installing the appropriate -utilities, label our file system and configure the policy. -</p> - -</body> -</subsection> -<subsection> -<title>Install Policies and Utilities</title> -<body> - -<p> -First, install the <path>sys-apps/checkpolicy</path> and -<path>sys-apps/policycoreutils</path> packages. Although these will be pulled in -as dependencies of the SELinux policy packages themselves, we need to install -these one time first - hence the <c>-1</c> option. -</p> - -<pre caption="Installing SELinux policy core utilities"> -~# <i>emerge -1 checkpolicy policycoreutils</i> -</pre> - -<p> -Next, install the SELinux policy package -(<path>sec-policy/selinux-base-policy</path>). This package contains the base -SELinux policy needed to get your system up and running using SELinux. -As Portage will try to label and reload policies (since the installation of -<path>sys-apps/policycoreutils</path>) we need to temporarily disable SELinux -support (as Portage wouldn't be able to label anything as it doesn't understand -it yet). -</p> - -<pre caption="Installing the SELinux policy packages"> -~# <i>FEATURES="-selinux" emerge selinux-base-policy</i> -</pre> - -<p> -Next, rebuild those packages affected by the profile change we did previously -through a standard world update, taking into account USE-flag changes (as the -new profile will change many default USE flags, including enabling the -<c>selinux</c> USE flag). Don't forget to use <c>etc-update</c> or -<c>dispatch-conf</c> afterwards as some changes to configuration files need to -be made. -</p> - -<pre caption="Update your Gentoo Linux system"> -~# <i>emerge -uDN world</i> -</pre> - -<p> -Next, install the additional SELinux tools that you might need in the future to -debug or help with your SELinux installation. These packages are optional, but -recommended. -</p> - -<pre caption="Installing additional SELinux packages"> -~# <i>emerge setools sepolgen checkpolicy</i> -</pre> - -<p> -Finally, install the policy modules for those utilities you think you need -policies for. In the near future, this will be done automatically for you (the -packages will have an optional dependency on it, triggered by the selinux USE -flag), but until that time, you will need to install them yourself. -</p> - -<pre caption="Installing SELinux modules"> -~# <i>emerge --search selinux-</i> -[...] -<comment>(Select the modules you want to install)</comment> -~# <i>emerge selinux-screen selinux-gnupg selinux-sudo selinux-ntp selinux-networkmanager ...</i> -</pre> - -</body> -</subsection> -<subsection> -<title>Configure the SELinux Policy</title> -<body> - -<p> -Inside <path>/etc/selinux/config</path> you can configure how SELinux is -configured at boot time. -</p> - -<pre caption="Editing the /etc/selinux/config file"> -# This file controls the state of SELinux on the system on boot. - -# SELINUX can take one of these three values: -# enforcing - SELinux security policy is enforced. -# permissive - SELinux prints warnings instead of enforcing. -# disabled - No SELinux policy is loaded. -SELINUX=<i>permissive</i> - -# SELINUXTYPE can take one of these four values: -# targeted - Only targeted network daemons are protected. -# strict - Full SELinux protection. -# mls - Full SELinux protection with Multi-Level Security -# mcs - Full SELinux protection with Multi-Category Security -# (mls, but only one sensitivity level) -SELINUXTYPE=<i>strict</i> -</pre> - -<p> -Within this configuration file, two variables can be set: -</p> - -<ul> - <li> - <c>SELINUX</c> sets how SELinux should behave: - <ul> - <li> - <c>enforcing</c> will enable and enforce policies. This is where we want - to go for, but you should probably start with <c>permissive</c>. - </li> - <li> - <c>permissive</c> will enable policies, but not enforce them. Any - violation is reported but not denied. This is where you should start - from as it will not impact your system yet allow you to get acquainted - with SELinux - and validate the warnings to see if you can switch - towards <c>enforcing</c> or not. - </li> - <li> - <c>disabled</c> will completely disable the policies. As this will not - show any violations as well, it is not recommended. - </li> - </ul> - </li> - <li> - <c>SELINUXTYPE</c> selects the SELinux policy type to load. - Gentoo Hardened recommends the use of <c>strict</c> for servers, and - <c>targeted</c> for desktops. The <c>mcs</c> type is supported, <c>mls</c> - is currently still considered experimental. - </li> -</ul> - -<p> -The differentiation between <c>strict</c> and <c>targeted</c> is based upon the -<e>unconfined</e> domain. When loaded, the processes on your system that are not -specifically confined within a particular policy module will be part of the -unconfined_t domain whose purpose is to allow most activities by default (rather -than deny by default). As a result, processes that run inside the unconfined_t -domain have no restrictions apart from those already enforced by standard Linux -security. Although running without the unconfined_t domain is considered more -secure, it will also be more challenging for the administrator to make sure the -system still functions properly as there are no policy modules for each and -every application "out there". -</p> - -<p> -Next to <c>targeted</c> and <c>strict</c>, you can opt for <c>mcs</c> to allow -categorization of the process domains. This is useful on multi-tenant systems -such as web servers, virtualization hosts, ... where multiple processes will be -running, most of them in the same security domain, but in different categories. -</p> - -<p> -Finally, you can also select <c>mls</c> to differentiate security domains on -a sensitivity level. However, MLS is currently still considered experimental -in Gentoo and as such not recommended. -</p> - -<p> -When you have made your choice between the SELinux policy types, save -this in your <path>/etc/make.conf</path> file as well. That way, Portage will -only install the policy modules for that SELinux type. -</p> - -<pre caption="Setting the policy type in make.conf"> -~# <i>nano /etc/make.conf</i> -POLICY_TYPES="<i>strict</i>" -</pre> - -</body> -</subsection> -<subsection> -<title>Reboot, and Label the File System</title> -<body> - -<impo> -Repeat these steps every time you have rebooted from a non-SELinux enabled -kernel into a SELinux enabled kernel, as running with a non-SELinux enabled -kernel will not update the security attributes of the files you create or -manipulate during your day-to-day activities on your system. -</impo> - -<p> -First reboot your system so that the installed policies are loaded. Now we -need to relabel your devices and openrc related files. This will apply the -correct security contexts (labels) onto the necessary files. -</p> - -<pre caption="Relabel /dev structure"> -~# <i>mkdir /mnt/gentoo</i> -~# <i>mount -o bind / /mnt/gentoo</i> - -<comment>(Substitute the "strict" in the next command with "targeted" if that is your SELINUXTYPE selection)</comment> -~# <i>setfiles -r /mnt/gentoo /etc/selinux/strict/contexts/files/file_contexts /mnt/gentoo/dev</i> -~# <i>setfiles -r /mnt/gentoo /etc/selinux/strict/contexts/files/file_contexts /mnt/gentoo/lib64</i> -~# <i>umount /mnt/gentoo</i> -</pre> - -<p> -Next, if you have a swapfile rather than a swap partition, label it accordingly: -</p> - -<pre caption="Labelling the swap file"> -~# <i>semanage fcontext -a -t swapfile_t "/swapfile"</i> -~# <i>restorecon /swapfile</i> -</pre> - -<p> -Now relabel your entire file system. The next command will apply the correct -security context onto the files on your file system, based on the security -context information provided by the SELinux policy modules installed. -</p> - -<pre caption="Relabel the entire file system"> -~# <i>rlpkg -a -r</i> -</pre> - -<p> -If you ever have to install a SELinux policy module for a package after that -that particular package is installed, you need to run <c>rlpkg</c> for that -package to make sure that the security contexts for these files are set -correctly. For instance, if you have installed -<path>sec-policy/selinux-screen</path> after discovering that you have -<c>screen</c> on your system: -</p> - -<pre caption="Relabeling the files for a single package"> -<comment>(Make sure no screen sessions are running as their security contexts will not be adapted)</comment> -~# <i>rlpkg -t screen</i> -</pre> - -</body> -</subsection> -<subsection> -<title>Reboot and Set SELinux Booleans</title> -<body> - -<p> -Reboot your system so that the newly applied file contexts are used. Log on -and, if you have indeed installed Gentoo using the hardened sources (as we -recommended), enable the SSP SELinux boolean, allowing every domain read -access to the <path>/dev/urandom</path> device: -</p> - -<pre caption="Enabling the global_ssp boolean"> -~# <i>setsebool -P global_ssp on</i> -</pre> - -</body> -</subsection> -<subsection> -<title>Define the Administrator Accounts</title> -<body> - -<p> -If the <c>SELINUXTYPE</c> is set to <c>strict</c>, then we -need to map the account(s) you use to manage your system (those -that need access to Portage) to the <c>staff_u</c> SELinux user. If not, none -of your accounts will be able to succesfully manage the system (except for -<c>root</c>, but then you will need to login as <c>root</c> directly and not -through <c>sudo</c> or <c>su</c>.) By default, users are mapped to the -<c>user_u</c> SELinux user who doesn't have the appropriate rights (nor access -to the appropriate roles) to manage a system. Accounts that are mapped to -<c>staff_u</c> can, but might need to switch roles from <c>staff_r</c> to -<c>sysadm_r</c> before they are granted the appropriate privileges. -</p> - -<p> -Assuming that your account name is <e>john</e>: -</p> - -<pre caption="Mapping the Linux account john to the SELinux user staff_u"> -~# <i>semanage login -a -s staff_u john</i> -~# <i>restorecon -R -F /home/john</i> -</pre> - -<p> -If you later log on as <e>john</e> and want to manage your system, you will -probably need to switch your role. You can use <c>newrole</c> for this: -</p> - -<pre caption="Switching roles"> -~$ <i>id -Z</i> -staff_u:staff_r:staff_t -~$ <i>newrole -r sysadm_r</i> -Password: <comment>(Enter your password)</comment> -~$ <i>id -Z</i> -staff_u:sysadm_r:sysadm_t -</pre> - -<p> -If you however use a <c>targeted</c> policy, then the user you work with will be -of type <e>unconfined_t</e> and will already have the necessary privileges to -perform system administrative tasks. -</p> - -<p> -With that done, enjoy - your first steps into the SELinux world are now made. -</p> - -</body> -</subsection> -</section> -</sections> diff --git a/xml/selinux/hb-using-policies.xml b/xml/selinux/hb-using-policies.xml deleted file mode 100644 index a67f20b..0000000 --- a/xml/selinux/hb-using-policies.xml +++ /dev/null @@ -1,520 +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-using-commands.xml,v 1.3 2011/06/07 19:46:52 klondike Exp $ --> - -<sections> -<version>4</version> -<date>2012-04-29</date> - -<section> -<title>SELinux Policy Language</title> -<subsection> -<title>Introduction</title> -<body> - -<p> -By default, Gentoo provides a generic, yet tightly controlled policy which is -deemed a good start policy for the majority of users. However, the purpose -behind a Mandatory Access Control system is to put the security administrator in -control. As such, a handbook on SELinux without information on how to write -policies wouldn't be complete. -</p> - -<p> -In this chapter, we'll talk a bit about the language behind SELinux policies and -give some pointers on how to create your own policies, roles, etc. -</p> - -</body> -</subsection> -<subsection> -<title>Building a SELinux Module</title> -<body> - -<p> -First, before we go into the art of SELinux policy writing, let's first make a -small SELinux module with a rule we can test, build the module and see if things -work. Although these steps are fairly easy, they are important nonetheless. -Modifying the SELinux policy as offered by Gentoo is best done through -additional SELinux policy modules. Only when the core policy (the base policy) -is not to your liking should you see on using a totally different policy. -</p> - -<p> -Let's start with a skeleton for a policy module we'll call <e>testmod</e>. You -should use simple names for the modules as the build infrastructure is quite -sensitive to special constructs. Use only letters a-z and numbers, and never -start a module name with a number. -</p> - -<pre caption="Policy module skeleton"> -policy_module(testmod, 1.0.0) -</pre> - -<p> -Yes, that's it. But as you can see, it is fairly empty. So let's add a rule that -allows a regular user (in the user_t domain) to read ebuild files (of type -portage_ebuild_t). -</p> - -<pre caption="Policy module testmod"> -policy_module(testmod, 1.0.0) - -require { - type user_t; - type portage_ebuild_t; - class file { read open getattr }; - class dir { read search open getattr }; -} - -allow user_t portage_ebuild_t:file { read open getattr }; -allow user_t portage_ebuild_t:dir { read search open getattr }; -</pre> - -<p> -As you can see, something as simple as allowing a user to read a file requires -quite a few privileges. The directory privileges are needed to allow a user to -navigate through the Portage tree structure whereas the file privileges are -needed for a user to be able to access and open the ebuilds. Save this file as -<path>testmod.te</path>. -</p> - -<p> -To build the policy and convert it into the binary module that we can load into -the SELinux policy store, we can use the <path>Makefile</path> available in -<path>/usr/share/selinux/strict/include</path> (substitute strict with the -SELinux policy type you are using). -</p> - -<pre caption="Building a binary policy module"> -$ <i>make -f /usr/share/selinux/struct/include/Makefile testmod.pp</i> -</pre> - -<p> -The filename (<path>testmod.pp</path>) is the destination binary SELinux module -name. The <path>Makefile</path> will automatically look for the -<path>testmod.te</path> file you have in the working directory. -</p> - -<p> -As a result, you should now have a file called <path>testmod.pp</path>. This -module file can now be loaded in the SELinux policy store as follows: -</p> - -<pre caption="Loading a binary module"> -# <i>semodule -i /path/to/testmod.pp</i> -</pre> - -<p> -Congratulations! You have now build your first SELinux policy module. If you -want to disable it, remove it through <c>semodule -r testmod</c>. -</p> - -<p> -This method of building a policy (using the <path>Makefile</path> and -<c>semodule</c>) is something that you will need to do every time you want to -update the SELinux policy on your system. The contents of the policy however -does change as we will see in the rest of this document. -</p> - -</body> -</subsection> -<subsection> -<title>Getting the SELinux Policy Interfaces</title> -<body> - -<p> -To streamline policy development, the SELinux policy based on the reference -policy uses interfaces to access privileges within a module. If you have built -<path>selinux-base-policy</path> with <c>USE="doc"</c> then this information is -available at -<path>/usr/share/doc/selinux-base-policy-<version>/html</path>. It is -recommended to have this information at hand, since most policy -development/updates will be done through the interfaces offered by the policy. -</p> - -<p> -If you are just interested, you can also find these interface definitions <uri -link="http://oss.tresys.com/docs/refpolicy/api/">online</uri>. Mind you though, -the online resource is only the reference policy and might differ a bit from the -policy available within Gentoo. -</p> - -</body> -</subsection> -<subsection> -<title>Using Policy Interfaces</title> -<body> - -<p> -Using the policy interfaces allows you to update the policy with more readable -functions. For instance, to allow the user_t domain to call and use Portage -applications, the module could look like so: -</p> - -<pre caption="Example policy to allow user_t to use portage"> -policy_module(testmod, 1.0.0) - -require { - type user_t; - role user_r; -} - -portage_run(user_t, user_r) -</pre> - -<p> -Of course, this makes the user_t domain much more privileged than the previously -defined rules to read ebuild files: it allows the user to call portage, update -the system, etc. Of course, the user still requires the proper regular Linux -permissions (so he needs to be part of the portage group or become root). -Needless to say, we do not recommend to grant this to a regular user ;-) -</p> - -</body> -</subsection> -</section> - -<section> -<title>Full SELinux Policy Modules</title> -<subsection> -<title>Checking Out an Isolated Module</title> -<body> - -<p> -With the above in mind, we can now go one step further and investigate a full -policy module, with both the type enforcement rules (<path>.te</path> file), -file contexts (<path>.fc</path>) and interfaces (<path>.if</path>). -</p> - -<p> -You should know that writing a module requires you to get intimate with the -application. It isn't a matter of just hoping for the best: as a security -administrator, you will be responsible for defining what accesses are allowed -and which not. If you forget one, the application might break under the users' -hands. But if you add too much, you might grant privileges that can be abused -later on. And it will be a lot more difficult to track and remove privileges -later as you will be hesitating if the privilege is needed or not. -</p> - -<p> -In this section, we will not divulge in how to write one. We have an excellent -<uri link="/proj/en/hardened/selinux-development.xml">Gentoo Hardened SELinux -Development</uri> resource that guides you in that. However, we will look into -such a full module to explain the other aspects of policy development. -</p> - -</body> -</subsection> -<subsection> -<title>Type Enforcement File</title> -<body> - -<p> -The <path>.te</path> file we wrote earlier is a <e>type enforcement file</e>. -Its purpose is to define the access rules related to the module that you are -building, but also - and more importantly - define new types (or even roles). -</p> - -<p> -The example below is a snippet from a module for the skype application. -</p> - -<pre caption="Snippet from skype.te"> -policy_module(skype, 1.0.0) - -type skype_t; -type skype_exec_t; -application_domain(skype_t, skype_exec_t) - -type skype_home_t; -userdom_user_home_content(skype_home_t) - -manage_dirs_pattern(skype_t, skype_home_t, skype_home_t) -manage_files_pattern(skype_t, skype_home_t, skype_home_t) -</pre> - -<p> -In the above example, three new types are declared: <c>skype_t</c> (which will -be used for the application), <c>skype_exec_t</c> (which is the label given to -the application binary) and <c>skype_home_t</c> (which will be used for the -users' <path>~/.Skype</path> location). Also, the <c>skype_t</c> domain is given -some privileges with respect to the <c>skype_home_t</c> label (manage -directories and files). -</p> - -</body> -</subsection> -<subsection> -<title>File Context File</title> -<body> - -<p> -In the <path>.fc</path> file (which stands for <e>file context file</e>) the -module's resources (files, directories, sockets, ...) are defined. Once the -module is loaded, these rules are added so that file system relabeling will put -the correct context on the files. -</p> - -<p> -The example below is a snippet from the skype modules' file context file. -</p> - -<pre caption="Snippet from skype.fc"> -HOME_DIR/\.Skype(/.*)? gen_context(system_u:object_r:skype_home_t,s0) -/opt/skype/skype -- gen_context(system_u:object_r:skype_exec_t,s0) -/usr/bin/skype -- gen_context(system_u:object_r:skype_exec_t,s0) -</pre> - -<p> -The format of the file context file has the following syntax: -</p> - -<ol> - <li> - The regular expression that matches the file(s) and directorie(s) affected - by that line - </li> - <li> - An optional identifier to differentiate the type of files (file, directory, - socket, symbolic link, ...) - </li> - <li> - A <c>gen_context</c> line that contains the context to assign to the file(s) - and directorie(s) - </li> -</ol> - -</body> -</subsection> -<subsection> -<title>Interface File</title> -<body> - -<p> -In the <path>.if</path> file (for <e>interface file</e>) interfaces are declared -which can be used by other modules. It is through interfaces that a nicely -defined policy can be built on top of other, existing policy modules. -</p> - -<p> -One interface could be to allow users to call and execute an application. For -instance, the following interface can be found in the skype module. -</p> - -<pre caption="Snippet from skype.if"> -interface(`skype_role',` - gen_require(` - type skype_t, skype_exec_t, skype_tmpfs_t, skype_home_t; - ') - - role $1 types skype_t; - - domtrans_pattern($2, skype_exec_t, skype_t) - - allow $2 skype_t:process { ptrace signal_perms }; - - manage_dirs_pattern($2, skype_home_t, skype_home_t) - manage_files_pattern($2, skype_home_t, skype_home_t) - manage_lnk_files_pattern($2, skype_home_t, skype_home_t) - - relabel_dirs_pattern($2, skype_home_t, skype_home_t) - relabel_files_pattern($2, skype_home_t, skype_home_t) - relabel_lnk_files_pattern($2, skype_home_t, skype_home_t) - - ps_process_pattern($2, skype_t) -') -</pre> - -<p> -Through this <c>skype_role</c>, we can then allow users to call skype, as can be -found in the <path>unprivuser.te</path> file (which defines the user_t domain): -</p> - -<pre caption="Snippet from unprivuser.te to call skype"> -optional_policy(` - skype_role(user_r, user_t) -') -</pre> - -<p> -The following table shows a few common interfaces that could be in use. We -seriously recommend to look at the available interfaces when enhancing or -creating your own modules - and be sure to pick the interface that adds just -what you need, nothing more. -</p> - -<table> -<tr> - <th colspan="3">Templates</th> -</tr> -<tr> - <th>Suffix</th> - <th>Example</th> - <th>Description</th> -</tr> -<tr> - <ti>_template</ti> - <ti>virt_domain_template(prefix)</ti> - <ti> - Not really an interface, templates create additional domains based on the - information given to them. This is usually done for fine-grained policy - templates with a common (sub)set of privileges. - </ti> -</tr> -<tr> - <th colspan="3">Transformations</th> -</tr> -<tr> - <th>Suffix</th> - <th>Example</th> - <th>Description</th> -</tr> -<tr> - <ti></ti> - <ti>miscfiles_cert_type(resource)</ti> - <ti> - Transformation interfaces generally add specific attributes to resources or - domains. Attributes "transform" the given resource into something more. In - the given example, the miscfiles_cert_type(resource) assigns the cert_type - attribute to the resource (and also marks it as a file). Interfaces, like - miscfiles_read_all_certs work on these attributes. - </ti> -</tr> -<tr> - <th colspan="3">Access interfaces</th> -</tr> -<tr> - <th>Suffix</th> - <th>Example</th> - <th>Description</th> -</tr> -<tr> - <ti>_<access>_<resource></ti> - <ti>mta_getattr_spool(domain)</ti> - <ti> - Grant the specified domain access towards the shown resource. The resource - usually defines the type too (like kudzu_getattr_exec_files: grant getattr - on the kudzu_exec_t files) unless it is obvious from the name, or when the - resource is a more specific term towards the domain. It can also include - dontaudit (like mta_dontaudit_getattr_spool). - </ti> -</tr> -<tr> - <ti>_exec</ti> - <ti>dmesg_exec(domain)</ti> - <ti> - Grant one domain the right to execute the given domains' executable file (in - the example, allow "domain" to execute dmesg_exec_t files), but without - implying that the domains transition. In other words, dmesg gets executed - but still confined by the privileges of the source domain. - </ti> -</tr> -<tr> - <ti>_domtrans</ti> - <ti>dmesg_domtrans(domain)</ti> - <ti> - Grant one domain execute and transition privileges towards the new domain. - This interface is most commonly used to allow application domains to - transition to another. In the given example, dmesg is ran with the - privileges of the dmesg_t domain. - </ti> -</tr> -<tr> - <ti>_run</ti> - <ti>netutils_run(domain, role)</ti> - <ti> - Grant a given role and domain the rights to execute and transition towards - the given domain. This is usually granted to (existing) user roles and - domains and gives them the set of privileges needed to interact safely with - the new (interactive) domain (such as terminal access). - </ti> -</tr> -<tr> - <ti>_role</ti> - <ti>xserver_role(role, domain)</ti> - <ti> - Allow the given role and domain the necessary permissions to transition and - interact with the given domain. This interface is enhanced with the - privileges to interact with the domain (and its underlying files) more - thoroughly, and is usually assigned to newly created users or roles within - the policy (rather than enhance existing user domains and roles). - </ti> -</tr> -<tr> - <ti>_admin</ti> - <ti>aide_admin(domain)</ti> - <ti> - Grant the given domain the rights to administer the target domains' - environment. This usually involves privileges to manage and relabel all - affiliated files, directories, sockets, etc. - </ti> -</tr> -</table> - -</body> -</subsection> -</section> - -<section> -<title>Using audit2allow</title> -<subsection> -<title>Introduction</title> -<body> - -<p> -When reading online resources on SELinux, you will notice that there are many -references to a tool called <c>audit2allow</c>. This tools' purpose is to read -AVC denial messages from the audit log file and transform them into a policy -module that you can load. The advantage is that it makes it a lot easier to -write policies. The downside is that the output (unless you use the <c>-R</c> -option) is not usable for the <path>Makefile</path> we used earlier to build -modules. -</p> - -<p> -Another disadvantage is that the tool does not intelligently cope with changes. -It blindly accepts denials and treats them as if they need to be allowed, rather -than investigate if no other context should be given to the file, etc. -</p> - -</body> -</subsection> -<subsection> -<title>Using audit2allow</title> -<body> - -<p> -Using <c>audit2allow</c> is pretty straightforward. You send it the denials you -want to fix and store the result in a <path>.te</path> file. You then convert it -into an intermediary format which can then be translated into a <path>.pp</path> -file for final loading by <c>semodule</c>. -</p> - -<p> -For instance, to catch all denials and transform them into allowed statements -from firefox-related denials: -</p> - -<pre caption="Generate a new policy using audit2allow"> -# <i>grep firefox /var/log/avc.log | audit2allow -m firefoxmod > firefoxmod.te</i> -# <i>checkmodule -m -o firefoxmod.mod firefoxmod.te</i> -# <i>semodule_package -o firefoxmod.pp -m firefoxmod.mod</i> -# <i>semodule -i firefoxmod.pp</i> -</pre> - -<p> -Keep the module name (given through the <c>-m</c> option) simple: only use -characters (<c>[a-z]</c>) and numbers (<c>[0-9]</c>), and start the module name -with a character. -</p> - -</body> -</subsection> -</section> - -</sections> diff --git a/xml/selinux/hb-using-states.xml b/xml/selinux/hb-using-states.xml deleted file mode 100644 index ee7f8e1..0000000 --- a/xml/selinux/hb-using-states.xml +++ /dev/null @@ -1,367 +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-using-commands.xml,v 1.3 2011/06/07 19:46:52 klondike Exp $ --> - -<sections> -<version>2</version> -<date>2012-04-29</date> - -<section> -<title>SELinux States</title> -<subsection> -<title>Introduction</title> -<body> - -<p> -When SELinux is available, it will generally be in one of three states on your -system: disabled, permissive or enforcing. -</p> - -</body> -</subsection> -<subsection> -<title>Disabled</title> -<body> - -<p> -When <c>getenforce</c> returns "Disabled", then SELinux is not running on your -system. Even though it might be built in your kernel, it is definitely disabled. -Your system will still run with regular discretionary access controls (the usual -permission rules for standard Linux environments) but the mandatory access -controls are not active. -</p> - -<p> -When SELinux is disabled, it also means that files, directories, etc that are -modified or created will not get the proper SELinux context assigned to them. -When you later start your system with SELinux enabled (permissive or enforcing), -issues will arise since the SELinux subsystem will not know which label the -files have (it will default the label to one that is not accessible by most -domains). -</p> - -<p> -The best way to go forward in such case is to boot in permissive mode and then -relabel the entire file system: -</p> - -<pre caption="Relabeling the entire file system"> -# <i>rlpkg -a -r</i> -</pre> - -</body> -</subsection> -<subsection> -<title>Permissive</title> -<body> - -<p> -When SELinux is enabled in permissive mode (<c>getenforce</c> returns -"Permissive"), then SELinux is enabled and it has a policy loaded. Every access -a process makes is checked against the policy rules and, if an access is not -allowed, it will be logged (unless the denial is marked as dontaudit) but it -will <e>not</e> be prohibited. -</p> - -<p> -The permissive mode is perfect to get acquainted with SELinux and have the -system made ready for future "enforcing" mode. While running in permissive mode, -applications <e>that are not SELinux aware</e> will behave as if SELinux is not -running. This is perfect to validate if a problem is caused by SELinux or not: -if in permissive mode the problem still persists, then it is not caused by -SELinux. -</p> - -<p> -There is one caveat though: if the application is <e>SELinux-aware</e> (it knows -that it can run in a SELinux environment and is able to make SELinux-specific -calls) it might still react differently. Although this is often (but not always) -a bad programming practice, some applications check if SELinux is enabled and -base their functional flow on the results, regardless of the state being -permissive or enforcing. -</p> - -<p> -To find out if an application is SELinux aware, simply check if it is linked -against libselinux (with <c>ldd</c> or <c>scanelf</c> - part of -<path>app-misc/pax-utils</path>): -</p> - -<pre caption="Checking if /bin/ls is SELinux-aware"> -# <i>scanelf -n /bin/ls</i> - TYPE NEEDED FILE -ET_DYN libselinux.so.1,librt.so.1,libc.so.6 /bin/ls -</pre> - -</body> -</subsection> -<subsection> -<title>Enforcing</title> -<body> - -<p> -If <c>getenforce</c> returns "Enforcing", then SELinux is loaded and will act -based on the policy. When a process tries some activity that is not allowed by -the policy, it will be logged (unless a dontaudit is set) and the activity will -not go through. This is the only mode where you can truely say that SELinux is -active, because it is only now that the policy is acted upon. -</p> - -</body> -</subsection> -<subsection> -<title>Switching States</title> -<body> - -<p> -Depending on your Linux kernel configuration, you can switch between states -using one of the following methods. The kernel configuration however can be made -so that some of these options are disabled (for instance, a fully hardened -system will not allow disabling SELinux in any way). -</p> - -<p> -Using the command <c>setenforce</c>: -</p> - -<pre caption="Switching between enforcing and permissive"> -<comment>(Switching to permissive mode)</comment> -# <i>setenforce 0</i> - -<comment>(Switching to enforcing mode)</comment> -# <i>setenforce 1</i> -</pre> - -<p> -Using the kernel boot option <c>enforcing</c>: -</p> - -<pre caption="Switching between enforcing and permissive through boot options"> -<comment>(The following GRUB kernel line would boot in permissive mode)</comment> -kernel /kernel-2.6.39-hardened-r8 root=/dev/md3 rootflags=data=journal <i>enforcing=0</i> -</pre> - -<p> -Using the <path>/etc/selinux/config</path> <c>SELINUX</c> variable: -</p> - -<pre caption="/etc/selinux/config SELINUX setting"> -# <i>cat /etc/selinux/config</i> -# This file controls the state of SELinux on the system on boot. - -# SELINUX can take one of these three values: -# enforcing - SELinux security policy is enforced. -# permissive - SELinux prints warnings instead of enforcing. -# disabled - No SELinux policy is loaded. -<i>SELINUX=enforcing</i> - -# SELINUXTYPE can take one of these four values: -# targeted - Only targeted network daemons are protected. -# strict - Full SELinux protection. -# mls - Full SELinux protection with Multi-Level Security -# mcs - Full SELinux protection with Multi-Category Security -# (mls, but only one sensitivity level) -SELINUXTYPE=strict -</pre> - -<p> -When you want to switch from permissive to enforcing, it is recommended to do so -in the order given above: -</p> - -<ol> - <li> - First boot up in permissive mode, log on, verify that your context is - correct (<c>id -Z</c>) and then switch to enforcing (<c>setenforce 1</c>). - You can now test if your system is still working properly. - </li> - <li> - Next, boot with <c>enforcing=1</c> as kernel parameter. This way, your - system will boot in enforcing mode, but if things go haywire, you can just - reboot, leave out the option and be back in permissive mode - </li> - <li> - Finally, edit <path>/etc/selinux/config</path> to persist this change. - </li> -</ol> - -</body> -</subsection> -<subsection> -<title>Domain-permissive Mode</title> -<body> - -<p> -You can also opt to mark a single domain permissive while running the rest of -the system in an enforcing state. For instance, to mark mplayer_t as a -permissive domain (which means that SELinux does not enforce anything): -</p> - -<pre caption="Marking mplayer_t as permissive"> -# <i>semanage permissive -a mplayer_t</i> -</pre> - -<p> -With the <c>-d</c> option, you can remove the permissive mark again. -</p> - -</body> -</subsection> -</section> - -<section> -<title>SELinux Policy Types</title> -<subsection> -<title>Introduction</title> -<body> - -<p> -Next to the SELinux state, SELinux also offers different policy types. These -types differentiate themselves in specific SELinux features that are enabled or -disabled. Within Gentoo, three are supported (and a fourth is available): -<c>targeted</c>, <c>strict</c>, <c>mcs</c> (and <c>mls</c>). -</p> - -<p> -The type used on a system is declared in <path>/etc/selinux/config</path>: -</p> - -<pre caption="The SELINUXTYPE information in /etc/selinux/config"> -# <i>cat /etc/selinux/config</i> -# This file controls the state of SELinux on the system on boot. - -# SELINUX can take one of these three values: -# enforcing - SELinux security policy is enforced. -# permissive - SELinux prints warnings instead of enforcing. -# disabled - No SELinux policy is loaded. -SELINUX=enforcing - -# SELINUXTYPE can take one of these four values: -# targeted - Only targeted network daemons are protected. -# strict - Full SELinux protection. -# mls - Full SELinux protection with Multi-Level Security -# mcs - Full SELinux protection with Multi-Category Security -# (mls, but only one sensitivity level) -<i>SELINUXTYPE=strict</i> -</pre> - -</body> -</subsection> -<subsection> -<title>strict (without unconfined domains)</title> -<body> - -<p> -The <c>strict</c> policy type is the policy type that was described in the -earlier chapters, and coincidentally the type that is the easiest to understand. -With the strict policy type, each and every application runs in a domain that -has limited privileges. Although there are highly privileged domains, they are -never truely unlimited in their privileges. -</p> - -</body> -</subsection> -<subsection> -<title>targeted (using unconfined domains)</title> -<body> - -<p> -The <c>targeted</c> policy type is similar to the strict one, with one major -addition: support for unconfined domains. Applications (or users) that run in an -unconfined domain are almost unlimited in their privileges. The unconfined -domains are usually used for users and user applications, but also the init -system and other domains are marked as "unconfined" domains. -</p> - -<p> -The idea behind the targeted policy is that network-facing services are running -in (confined) regular domains whereas the rest uses the standard discretionary -access controls offered by Linux. These other domains are running as -"unconfined". -</p> - -</body> -</subsection> -<subsection> -<title>mcs (using multiple categories)</title> -<body> - -<p> -The introduction of <c>mls</c> and <c>mcs</c> offers the ability for -<e>multi-tenancy</e>: multiple instances of the same application should be able -to run, but each instance should be confined with respect to the others (instead -of all these processes running in the same domain and, hence, the same -privileges). -</p> - -<p> -A simple example is virtualization: a virtual guest which runs in the -<c>qemu_t</c> domain needs write privileges on the image file that contains the -guest operating system. However, if you run two guests, you do not want each -guest to write to the other guests' file. With regular domains, you will need to -provide this. With <c>mcs</c>, you can give each running instance a specific -category (number) and only grant it write privileges to the guest file with the -correct category (number). -</p> - -</body> -</subsection> -<subsection> -<title>mls (using multiple security levels)</title> -<body> - -<p> -The <c>mls</c> policy type is available but not yet supported by Gentoo -Hardened. With this policy type, it is possible to give sensitivity levels on -files and resources as well as domains. Sensitivity levels can best be expressed -in terms of <e>public</e>, <e>private</e>, <e>confidential</e> or <e>strictly -confidential</e>. With MLS, you can mark a file as one (or a set of) -sensitivity level(s) and ensure that only domains with the right sensitivity -level can access it. -</p> - -</body> -</subsection> -<subsection> -<title>Switching Types</title> -<body> - -<p> -It is not recommended to switch between types often. At best, you choose your -policy type at install time and stick with it. But it is not impossible (nor -that hard) to switch between types. -</p> - -<p> -First, you need to edit <path>/etc/selinux/config</path> so that it both -switches the policy type as well as put the mode in <e>permissive</e>. This is -necessary, since at your next reboot, many labels might (or will) be incorrect. -</p> - -<p> -Next, edit <path>/etc/fstab</path> and make sure that the domains you use there -are updated accordingly. For instance, the line for <path>/tmp</path>: -</p> - -<pre caption="Changing /etc/fstab"> -<comment># Example when switching from strict to mcs</comment> -tmpfs /tmp tmpfs defaults,noexec,nosuid,rootcontext=system_u:object_r:tmp_t<i>:c0</i> 0 0 -</pre> - -<p> -When this is done, reboot your system. Log on as root, and relabel your entire -file system using <c>rlpkg -a -r</c>. Finally, reboot again and then validate if -your context (such as when logged on as a user) is correct again. Once you are -confident that the domains and contexts are correct, switch the SELinux policy -mode back to "enforcing". -</p> - -</body> -</subsection> -</section> - -</sections> diff --git a/xml/selinux/hb-using-troubleshoot.xml b/xml/selinux/hb-using-troubleshoot.xml deleted file mode 100644 index fc0323d..0000000 --- a/xml/selinux/hb-using-troubleshoot.xml +++ /dev/null @@ -1,349 +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-appendix-troubleshoot.xml,v 1.2 2011/04/25 20:12:59 zorry Exp $ --> - -<sections> -<version>2</version> -<date>2012-04-10</date> - -<section> -<title>Unable To Load SELinux Policy</title> -<subsection> -<title>Problem Description</title> -<body> - -<p> -If you notice that SELinux is not functioning at all, a quick run of -<c>sestatus</c> should give you closure if SELinux is enabled and loaded or not. -If you get the following output, no SELinux policy is loaded: -</p> - -<pre caption="sestatus output"> -SELinux status: disabled -</pre> - -<p> -If this is the case, read on in this section to find out how to troubleshoot and -resolve this. -</p> - -</body> -</subsection> -<subsection> -<title>No Policy Installed</title> -<body> - -<p> -One potential reason would be that there is no policy to load to begin with. -Take a look inside <path>/usr/share/selinux/strict</path> or -<path>/usr/share/selinux/targeted</path> (depending on your configuration) and -look for a file called <path>base.pp</path>. If no such file exists, you will -need to install the base policy. This policy is offered by the -<path>sec-policy/selinux-base-policy</path> package, but it is better to read up -on the chapter regarding <uri link="?part=2&chap=1">Gentoo SELinux -Installation / Conversion</uri> as more important changes might be missing. -</p> - -</body> -</subsection> -<subsection> -<title>Policy Not Loaded</title> -<body> - -<p> -If the <path>base.pp</path> file exists in -<path>/usr/share/selinux/strict</path> (or <path>targeted/</path>), take a look -inside <path>/etc/selinux/strict/policy</path>. This location too should contain -a <path>base.pp</path> policy module (when a SELinux policy is loaded, it is -copied from the first location to the second). -</p> - -<p> -If no <path>base.pp</path> file exists, install and load the policy: -</p> - -<pre caption="Installing the base policy"> -~# <i>semodule -n -B</i> -</pre> - -<p> -This is a one-time operation - once installed and loaded, it will be reloaded -upon every reboot. -</p> - -</body> -</subsection> -<subsection> -<title>Init Can Not Load the SELinux Policy</title> -<body> - -<p> -During system boot, the <c>init</c> process is responsible for loading and -interacting with the SELinux policy in memory. If <c>init</c> does not support -SELinux, you will get no SELinux support in your environment. -</p> - -<p> -To verify if <c>init</c> supports SELinux, we need to check if it uses the -<path>libselinux.so</path> shared object: -</p> - -<pre caption="Checking if init supports SELinux"> -~# <i>ldd /sbin/init</i> - linux-vdso.so.1 => (0x00006ace30e84000) - <comment>( You should see something similar to the following line: )</comment> - libselinux.so.1 => /lib/libselinux.so.1 (0x00006ace30a46000) - libc.so.6 => /lib/libc.so.6 (0x00006ace306e9000) - libdl.so.2 => /lib/libdl.so.2 (0x00006ace304e5000) - /lib64/ld-linux-x86-64.so.2 (0x00006ace30c68000) -</pre> - -<p> -If this is not the case, make sure that <c>emerge --info</c> shows that the -selinux USE flag is in place, and reinstall <path>sys-apps/sysvinit</path>. If -the selinux USE flag is not in place, check your Gentoo profile and make sure it -points to a <path>selinux/v2refpolicy/...</path> profile. -</p> - -</body> -</subsection> -<subsection> -<title>Policy Store is Corrupt</title> -<body> - -<p> -If you encounter problems during boot-up or <c>semodule</c> operations which -fail with loading problems, but cannot be resolved with the above solution, then -you might need to reinstall the policies after eliminating the corrupt store. -</p> - -<pre caption="Recovering from store corruption"> -~# <i>semodule -n -B</i> -libsemanage.semanage_load_module: Error while reading from module file -/etc/selinux/targeted/modules/tmp/base.pp. (No such file or directory) - -~# <i>setenforce 0</i> -~# <i>mv /etc/selinux/targeted /etc/selinux/targeted.old</i> -~# <i>FEATURES="-selinux" emerge -1av $(qlist -IC sec-policy)</i> -~# <i>restorecon -R /etc/selinux</i> -</pre> - -<p> -This will effectively disable the current, corrupted SELinux policy store and -then use Portage to reinstall all SELinux policy packages that are installed on -the system. When done, the file contexts of <path>/etc/selinux</path> are -restored, after which you should be able to continue. -</p> - -</body> -</subsection> -</section> - -<section> -<title>Unable to Log On</title> -<subsection> -<title>Problem Description</title> -<body> - -<p> -If you are unable to log on in a particular situation (remote, local, as root, -as regular user, ...) there are a few possible problems which you might have -hit. However, to resolve them you'll need to be able to log on to the system as -<e>sysadm_r</e> in one way or the other. -</p> - -<p> -If you can not log in as a <e>sysadm_r</e> user, disable SELinux (boot with -<c>enforcing=0</c>) so that no SELinux enforcements are made. Changes that you -make in permissive mode are equally effective as in enforcing mode. -</p> - -</body> -</subsection> -<subsection> -<title>Incorrect Context</title> -<body> - -<p> -In the majority of cases will you find that a security context is incorrect. Run -<c>sestatus -v</c> and compare the <e>Process contexts</e> or <e>File -contexts</e> that you see in the output with the next table. -</p> - -<table> -<tr> - <th>Process</th> - <th>Context</th> - <th>If wrong context...</th> -</tr> -<tr> - <ti>Init context</ti> - <ti>system_u:system_r:init_t</ti> - <ti> - First, verify that init itself is correclty labeled. Check the output of - the previously run <c>sestatus -v</c> command for the - <path>/sbin/init</path> file and make sure that it is set to - system_u:object_r:init_exec_t. If that is not the case, relabel - <path>sys-apps/sysvinit</path> using <c>rlpkg sysvinit</c>. Also make the - same checks as in the <uri link="#doc_chap1">Unable To Load SELinux - Policy</uri> section. Reboot your system and retry. - </ti> -</tr> -<tr> - <ti>agetty context</ti> - <ti>system_u:system_r:getty_t</ti> - <ti> - Make sure that the <path>/sbin/agetty</path> binary is labeled - system_u:object_r:getty_exec_t. If not, relabel the - <path>sys-apps/util-linux</path> package using <c>rlpkg util-linux</c>. Then - restart all the agetty processes using <c>pkill agetty</c> (they will - automatically respawn). - </ti> -</tr> -<tr> - <th>File</th> - <th>Context</th> - <th>If wrong context...</th> -</tr> -<tr> - <ti>/bin/login</ti> - <ti>system_u:object_r:login_exec_t</ti> - <ti> - The login binary is part of <path>sys-apps/shadow</path>. Run <c>rlpkg - shadow</c> to relabel the files of that package and retry logging in. - </ti> -</tr> -<tr> - <ti>/sbin/unix_chkpwd</ti> - <ti>system_u:object_r:chkpwd_exec_t</ti> - <ti> - This binary is part of the <path>sys-libs/pam</path> package and is used by - SSH when it is configured to use PAM for user authentication. Relabel the - package using <c>rlpkg pam</c> and retry logging in. - </ti> -</tr> -<tr> - <ti>/etc/passwd</ti> - <ti>system_u:object_r:etc_t</ti> - <ti rowspan="2"> - The <path>/etc/passwd</path> and <path>/etc/shadow</path> must be labeled - correctly, otherwise PAM will not be able to authenticate any user. Relabel - the files through <c>restorecon /etc/passwd /etc/shadow</c> and retry - logging in. - </ti> -</tr> -<tr> - <ti>/etc/shadow</ti> - <ti>system_u:object_r:shadow_t</ti> -</tr> -<tr> - <ti>/bin/bash</ti> - <ti>system_u:object_r:shell_exec_t</ti> - <ti> - The users' shell (in this case, <c>bash</c>) must be labeled correctly so - the user can transition into the user domain when logging in. To do so, - relabel the <path>app-shells/bash</path> package using <c>rlpkg bash</c>. - Then, try logging in again. - </ti> -</tr> -</table> - -</body> -</subsection> -</section> - -<section> -<title>Unable to Emerge Anything (OSError: [Errno 22] Invalid argument)</title> -<subsection> -<title>Problem Description</title> -<body> - -<p> -When trying to install software with Portage, you get a huge python stacktrace -and finally the error message <e>OSError: [Errno 22] Invalid argument</e>: -</p> - -<pre caption="Stacktrace dump when portage fails to install software"> -Traceback (most recent call last): - File "/usr/bin/emerge", line 43, in <module> - retval = emerge_main() - File "/usr/lib64/portage/pym/_emerge/main.py", line 1906, in emerge_main - myopts, myaction, myfiles, spinner) - File "/usr/lib64/portage/pym/_emerge/actions.py", line 437, in action_build - retval = mergetask.merge() -... - File "/usr/lib64/portage/pym/portage/package/ebuild/doebuild.py", line 104, in _doebuild_spawn - return spawn(cmd, settings, **kwargs) - File "/usr/lib64/portage/pym/portage/package/ebuild/doebuild.py", line 1255, in spawn - return spawn_func(mystring, env=mysettings.environ(), **keywords) - File "/usr/lib64/portage/pym/portage/_selinux.py", line 105, in wrapper_func - setexec(con) - File "/usr/lib64/portage/pym/portage/_selinux.py", line 79, in setexec - if selinux.setexeccon(ctx) < 0: -OSError: [Errno 22] Invalid argument -</pre> - -</body> -</subsection> -<subsection> -<title>Wrong Context</title> -<body> - -<p> -The above error comes when you launch portage (through <c>emerge</c>) while you -are not in <c>sysadm_t</c> context. You can verify this with <c>id -Z</c>: -</p> - -<pre caption="Checking current context"> -~# <i>id -Z</i> -system_u:system_r:local_login_t -</pre> - -<p> -As long as the context isn't <c>sysadm_t</c>, then Portage will break. This is -because Portage wants to switch its execution context from <c>portage_t</c> to -<c>portage_sandbox_t</c> but fails (it isn't in <c>portage_t</c> to begin with -because the user who launched Portage isn't in <c>sysadm_t</c>). -</p> - -<p> -Please check <uri link="#doc_chap2">Unable to Log On</uri> above first. Also -make sure that you can <c>dispatch-conf</c> or <c>etc-update</c> after -installing SELinux so that <path>/etc/pam.d/system-login</path> is updated with -the right <path>pam_selinux.so</path> calls. -</p> - -</body> -</subsection> -<subsection> -<title>Forcing Installation</title> -<body> - -<p> -If you need to force Portage to continue regardless (for instance, you were in -the middle of a SELinux installation so cannot properly resolve such issues -now), run the <c>emerge</c> command but with <c>FEATURES="-selinux"</c>. This -will effectively disable Portage' SELinux integration, but allows you to -continue installing software. -</p> - -<pre caption="Running emerge without selinux support"> -~# <i>FEATURES="-selinux" emerge -u world</i> -</pre> - -<p> -Make sure that you relabel the entire file system after using this approach! -Portage will not label the files installed on the system correctly if you -disable its SELinux support. To relabel the entire file system, use <c>rlpkg -a --r</c>. -</p> - -</body> -</subsection> -</section> - -</sections> diff --git a/xml/selinux/index.xml b/xml/selinux/index.xml deleted file mode 100644 index 08fc361..0000000 --- a/xml/selinux/index.xml +++ /dev/null @@ -1,156 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?> -<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?> -<!DOCTYPE project SYSTEM "/dtd/project.dtd"> -<!--$Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/index.xml,v 1.43 2011/04/25 20:12:59 zorry Exp $--> -<project> - -<name>SELinux</name> -<longname>SELinux</longname> - -<description> -SELinux is a system of mandatory access controls. SELinux can enforce -the security policy over all processes and objects in the system. -</description> - -<longdescription> -<p> -This project manages SELinux support in Gentoo. This includes providing -kernels with SELinux support, providing patches to userland utilities, writing -strong Gentoo-specific default profiles, and maintaining a good default set of -policies. -</p> - -<p> -<uri link="http://www.nsa.gov/research/selinux/index.shtml">Security-Enhanced -Linux</uri> (SELinux) is a Mandatory Access Control system using type -enforcement and role-based access control. It is integrated within Linux as a -<uri link="http://lsm.immunix.org/">Linux Security Module</uri> (LSM) -implementation. In addition to the kernel portion, SELinux consists of a library -(libselinux) and userland utilities for compiling policy (checkpolicy), and loading -policy (policycoreutils), in addition to other user programs. -</p> - -<p> -One common misconception is that SELinux is a complete security solution. It is -not. SELinux only provides access control on system objects. It can work well -with other Hardened projects, such as PaX, for a more complete solution. -</p> - -</longdescription> - -<goals> -<p> -Our goal is to make SELinux (with Gentoo Hardened) available to more users. -As a result, we -</p> - -<ul> - <li> - develop, improve and maintain the proper documentation and learning - material for end users to master SELinux - </li> - <li> - maintain a stable yet progressive set of userland tools that are needed - to interoperate with SELinux on a Linux system (such as the core utilities, - libselinux and more) - </li> - <li> - focus on the integration of SELinux and SELinux-awareness within the Gentoo - distribution, offering the necessary feedback on Portage and other utilities - </li> - <li> - develop, improve and maintain a good and secure default policy, based on the - reference policy, so that end users have no difficulties working with and - enhancing SELinux within their environment - </li> -</ul> -</goals> - -<dev role="lead" description="Documentation, Userspace tools, Policy development">SwifT</dev> -<dev role="developer" description="Policy development, Userspace tools">pebenito</dev> -<dev role="developer" description="Policy development, Proxy (non developer contributors)">blueness</dev> -<dev role="developer" description="Policy development, Support">prometheanfire</dev> - -<resource link="/proj/en/hardened/selinux/selinux-handbook.xml">Gentoo SELinux Handbook (concepts, installation, maintenance)</resource> -<resource link="/proj/en/hardened/selinux-faq.xml">Gentoo SELinux FAQ</resource> -<resource link="/proj/en/hardened/selinux-development.xml">Gentoo Hardened SELinux Development Guide</resource> -<resource link="/proj/en/hardened/selinux-bugreporting.xml">Reporting SELinux (policy) bugs</resource> -<resource link="/proj/en/hardened/selinux-policy.xml">Gentoo Hardened SELinux Development Policy</resource> -<resource link="/proj/en/hardened/roadmap.xml">Gentoo Hardened Roadmap (includes SELinux development)</resource> -<resource link="/proj/en/hardened/support-state.xml">Gentoo Hardened Support Matrices (includes SELinux)</resource> - -<extrachapter position="devs"> -<title>Contributors</title> -<section> -<body> - -<p> -The following people, although non-developer, are actively contributing to the project: -</p> -<table> -<tr><th>Contributor</th><th>Nickname</th><th>Role</th></tr> -<tr><ti>Chris Richards</ti><ti>gizmo</ti><ti>Policy development, support</ti></tr> -</table> - -</body> -</section> -</extrachapter> - -<extrachapter position="bottom"> -<title>I Want to Participate</title> -<section> -<body> -<p> -To participate in the SELinux project first join the mailing list at -<c>gentoo-hardened@gentoo.org</c>. Then ask if there are plans to support -something that you are interested in, propose a new subproject that you are -interested in or choose one of the planned subprojects to work on. You may talk -to the developers and users in the IRC channel <c>#gentoo-hardened</c> on -<c>irc.freenode.net</c> for more information or just to chat about the project -or any subprojects. If you don't have the ability to actively help by -contributing work we will always need testers to use and audit the SELinux -policies. All development, testing, feedback, and productive comments will -be greatly appreciated. -</p> -</body> -</section> - -<section> -<title>Policy Submissions</title> -<body> - -<p> -The critical component of a SELinux system is having a strong policy. The -team does its best to support as many daemons as possible. However, we cannot -create policies for daemons with which we are unfamiliar. But we are happy -to receive policy submissions for consideration. There are a few requirements: -</p> - -<ul> - <li> - Make comments (in the policy and/or bug), so we can understand changes - from the Reference Policy example policy. - </li> - <li> - The policy should cover common installations. Please do not submit policies - for odd or nonstandard daemon configurations. - </li> - <li> - We need to know if the policy is dependent on another policy (for example - rpcd is dependent on portmap) other than base-policy. - </li> -</ul> - -<p> -The policy should be submitted on <uri link="http://bugs.gentoo.org/">bugzilla</uri>. -Please attach the .te and .fc files separately to the bug, not as a tarball. -The bug should be Cc'ed to <c>selinux@gentoo.org</c> and will be properly -reassigned by the team. -</p> - -</body> -</section> -</extrachapter> - -</project> diff --git a/xml/selinux/selinux-handbook.xml b/xml/selinux/selinux-handbook.xml deleted file mode 100644 index 9801448..0000000 --- a/xml/selinux/selinux-handbook.xml +++ /dev/null @@ -1,199 +0,0 @@ -<?xml version='1.0' encoding='UTF-8'?> -<!DOCTYPE book SYSTEM "/dtd/book.dtd"> - -<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/selinux-handbook.xml,v 1.11 2011/04/25 20:12:59 zorry Exp $ --> - -<book> -<title>Gentoo SELinux Handbook</title> - -<author title="Author"> - <mail link="pebenito@gentoo.org">Chris PeBenito</mail> -</author> -<author title="Author"> - <mail link="sven.vermeulen@siphos.be">Sven Vermeulen</mail> -</author> -<author title="Author"> - Chris Richards -</author> - -<abstract> -This is the Gentoo SELinux Handbook. -</abstract> - -<!-- The content of this document is licensed under the CC-BY-SA license --> -<!-- See http://creativecommons.org/licenses/by-sa/1.0 --> -<license/> - -<version>4</version> -<date>2011-09-18</date> - -<part> -<title>Introduction to Gentoo/Hardened SELinux</title> -<abstract> -In this part we cover what SELinux is and how it is positioned within the -Gentoo/Hardened project. -</abstract> - -<chapter> -<title>Enhancing Linux Security</title> -<abstract> -Security is more than enabling a certain framework or installing a different -Linux kernel. It is a way of working / administrating your Gentoo Linux system. -We cover a few (generic) best practices, and then elaborate on what Mandatory -Access Control is and how SELinux fills in this gap. -</abstract> - <include href="hb-intro-enhancingsecurity.xml"/> -</chapter> - -<chapter> -<title>SELinux Concepts</title> -<abstract> -To be able to properly work with SELinux, it is vital that you understand a few -of its concepts like domains, domain transitions and file contexts. Without -a basic understanding of these aspects, it will be difficult to understand -how SELinux policies work and how to troubleshoot if things go wrong. -</abstract> - <include href="hb-intro-concepts.xml"/> -</chapter> - -<chapter> -<title>SELinux Resources</title> -<abstract> -To get more acquainted with SELinux, many resources exist on the Internet. -In this chapter we give a quick overview of the various resources as well -as places where you can get more help when you are fighting with SELinux. -</abstract> - <include href="hb-intro-resources.xml"/> -</chapter> - -<!-- -<chapter> -<title>The SELinux (Reference) Policy</title> -<abstract> -To streamline SELinux policy development, a reference policy is being developed -that is used by all SELinux-supporting distributions. In this chapter we give -some intel on what this reference policy is and why it is brought to life, but -also how this policy functions and how its development is progressing. We also -cover the basics on SELinux policies in general. -</abstract> - <include href="hb-intro-referencepolicy.xml"/> -</chapter> - -<chapter> -<title>SELinux Virtual Machine Support</title> -<abstract> -SELinux support is being actively integrated in libvirt and other -virtualization frameworks to elevate the security of virtualized -environments. Within this chapter we give you a first introduction -on how this is done for libvirt managed environments and what you need to take -into account if you wish to use SELinux within your virtualized environment. -</abstract> - <include href="hb-intro-virtualization.xml"/> -</chapter> ---> -</part> - -<part> -<title>Using Gentoo/Hardened SELinux</title> -<abstract> -With the theoretic stuff behind us, let us start by installing Gentoo/Hardened -with a SELinux kernel as well as the SELinux tools. -</abstract> - -<chapter> -<title>Gentoo SELinux Installation / Conversion</title> -<abstract> -To set up SELinux within Gentoo/Hardened, you first need to install Gentoo with -the correct Hardened profile (or convert to the Hardened profile) and then -update your system to become a SELinux-managed system. This chapter will guide -you through this process. -</abstract> - <include href="hb-using-install.xml"/> -</chapter> - -<chapter> -<title>Configuring SELinux For Your Needs</title> -<abstract> -With SELinux now "installed" and enabled (although in permissive mode), we now -configure it to suit your particular needs. After all, SELinux is a Mandatory -Access Control system where you, as security administrator, define what is -allowed and what not. -</abstract> - <include href="hb-using-configuring.xml"/> -</chapter> - -<chapter> -<title>SELinux Commands</title> -<abstract> -Let's take a step back and get to know a few more commands. We covered most of -them in the previous section, but we will now dive a bit deeper in its -syntax, features and potential pitfalls. -</abstract> - <include href="hb-using-commands.xml"/> -</chapter> - -<chapter> -<title>Permissive, Unconfined, Disabled or What Not...</title> -<abstract> -Your system can be in many SELinux states. In this chapter, we help you switch -between the various states / policies. -</abstract> - <include href="hb-using-states.xml"/> -</chapter> - -<chapter> -<title>Modifying the Gentoo Hardened SELinux Policy</title> -<abstract> -Gentoo Hardened offers a default policy, but this might not allow what you want -(or allows too much). In this chapter we tell you how you can tweak Gentoo's -policy, or even run your own. -</abstract> - <include href="hb-using-policies.xml"/> -</chapter> - -<chapter> -<title>Troubleshooting SELinux</title> -<abstract> -Everything made by a human can and will fail. In this chapter we will try to -keep track of all potential issues you might come across and how to resolve -them. -</abstract> - <include href="hb-using-troubleshoot.xml"/> -</chapter> -</part> - -<!-- -<part> -<title>Advanced SELinux</title> -<abstract> -SELinux can be much more integrated in the system. In this part, we describe how -to enhance SELinux configurations, tuning and securing your system even more. -</abstract> - -<chapter> -<title>Working with MLS</title> -<abstract> -... -</abstract> - <include href="hb-advanced-mls.xml"/> -</chapter> - -<chapter> -<title>Using s(ecure) Virt(ualization)</title> -<abstract> -... -</abstract> - <include href="hb-advanced-svirt.xml"/> -</chapter> - -<chapter> -<title>Using Netlabel</title> -<abstract> -... -</abstract> - <include href="hb-advanced-netlabel.xml"/> -</chapter> -</part> ---> - -</book> |