Gentoo Hardened SELinux Frequently Asked Questions

From 1439140807dfa46775a8b6fb1de0749ce665cb62 Mon Sep 17 00:00:00 2001 From: Sven Vermeulen Date: Sat, 26 May 2012 17:54:46 +0200 Subject: 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. --- xml/selinux-faq.xml | 952 ---------------------------- xml/selinux/hb-intro-concepts.xml | 910 -------------------------- xml/selinux/hb-intro-enhancingsecurity.xml | 387 ------------ xml/selinux/hb-intro-referencepolicy.xml | 255 -------- xml/selinux/hb-intro-resources.xml | 111 ---- xml/selinux/hb-intro-virtualization.xml | 25 - xml/selinux/hb-using-commands.xml | 492 --------------- xml/selinux/hb-using-configuring.xml | 981 ----------------------------- xml/selinux/hb-using-install.xml | 741 ---------------------- xml/selinux/hb-using-policies.xml | 520 --------------- xml/selinux/hb-using-states.xml | 367 ----------- xml/selinux/hb-using-troubleshoot.xml | 349 ---------- xml/selinux/index.xml | 156 ----- xml/selinux/selinux-handbook.xml | 199 ------ 14 files changed, 6445 deletions(-) delete mode 100644 xml/selinux-faq.xml delete mode 100644 xml/selinux/hb-intro-concepts.xml delete mode 100644 xml/selinux/hb-intro-enhancingsecurity.xml delete mode 100644 xml/selinux/hb-intro-referencepolicy.xml delete mode 100644 xml/selinux/hb-intro-resources.xml delete mode 100644 xml/selinux/hb-intro-virtualization.xml delete mode 100644 xml/selinux/hb-using-commands.xml delete mode 100644 xml/selinux/hb-using-configuring.xml delete mode 100644 xml/selinux/hb-using-install.xml delete mode 100644 xml/selinux/hb-using-policies.xml delete mode 100644 xml/selinux/hb-using-states.xml delete mode 100644 xml/selinux/hb-using-troubleshoot.xml delete mode 100644 xml/selinux/index.xml delete mode 100644 xml/selinux/selinux-handbook.xml 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 @@ - - - - - -Gentoo Hardened SELinux Frequently Asked Questions - - Chris PeBenito - - - Sven Vermeulen - - - -Frequently Asked Questions on SELinux integration with Gentoo Hardened. -The FAQ is a collection of solutions found on IRC, mailinglist, forums or -elsewhere - - -23 -2012-05-21 - - -Questions -

-Introduction - - -

-Using SELinux requires administrators a more thorough knowledge of their -system and a good idea on how processes should behave. Next to the Gentoo Hardened SELinux -handbook, a proper FAQ allows us to inform and help users in their -day-to-day SELinux experience. -

- -

-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. -

- - -

- - - -General SELinux Support Questions -

-Does SELinux enforce resource limits? - - -

-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. -

- - -

-Can I use SELinux with grsecurity (and PaX)? - - -

-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. -

- - -

-Can I use SELinux and the hardened compiler (with PIE-SSP)? - - -

-Definitely. We also suggest to use PaX to take full advantage of the PIE -features of the compiler. -

- - -

-Can I use SELinux and RSBAC? - - -

-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. -

- -

-In most cases, it makes more sense to use RSBAC without SELinux, or SELinux -without RSBAC. -

- - - - -

-Can I use SELinux with any file system? - - -

-SELinux requires access to a file's security context to operate properly. -To do so, SELinux uses extended file attributes 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. -

- -

-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. -

- -

-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. -

- -

-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. -

- - -

-Can I use SELinux with AMD64 no-multilib? - - - - -

-Yes, just use the hardened/linux/amd64/no-multilib/selinux profile -and you're all set. -

- - -

-What is UBAC exactly? - - -

-UBAC, or User Based Access Control, introduces additional constraints -when using SELinux policy. Participating domains / types that are both -marked as a ubac_constrained_type (which is an attribute) will only -have the allowed privileges in effect if they both run with the same SELinux -user context. -

- -

-# The SELinux allow rule
-allow foo_t bar_t:file { read };
-
-# This will succeed:
-staff_u:staff_r:foo_t reads file with type staff_u:object_r:bar_t
-
-# This will be prohibited:
-user_u:user_r:foo_t reads file with type staff_u:object_r:bar_t
-

- -

-Of course, this is not always the case. Besides the earlier mentioned -requirement that both types are ubac_constrained_type, if the source -domain is sysadm_t, then the constraint will not be in effect (the -sysadm_t domain is exempt from UBAC constraints). Also, if the source -or destination SELinux user is system_u then the constraint will also -not be in effect. -

- - -

- - - -Using SELinux -

-How do I enable SELinux? - - -

-This is explained in the SELinux Handbook -in the chapter on Using Gentoo/Hardened SELinux. -

- - -

-How do I switch between permissive and enforcing? - - -

-The easiest way is to use the setenforce command. With setenforce -0 you tell SELinux to run in permissive mode. Similarly, with -setenforce 1 you tell SELinux to run in enforcing mode. -

- -

-You can also add a kernel option enforcing=0 or enforcing=1 -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. -

- -

-The default state of the system is kept in /etc/selinux/config. -

- - -

-How do I disable SELinux completely? - - -

-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 /etc/selinux/config and set SELINUX=disabled. Next, -reboot your system. -

- - -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. - - - -

-How do I know which file context rule is used for a particular file? - - -

-If you use the matchpathcon 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 findcon: -

- -

-~# findcon /etc/selinux/strict/contexts/files/file_contexts -p /lib64/rc/init.d
-/.*                          system_u:object_r:default_t
-/lib64/rc/init\.d(/.*)?   system_u:object_r:initrc_state_t
-/lib64/.*                    system_u:object_r:lib_t
-

- -

-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. -

- -

-The most specific means, in order of tests: -

- -

- If line A has a regular expression, and line B doesn't, then line B is more - specific. -
- 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 -
- If the number of characters in line A is less than in line B, then line B is - more specific -
- If line A does not map to a specific SELinux type, and line B does, then - line B is more specific -

- -

-However, when you add your own file contexts (using semanage), this does -not apply. Instead, tools like restorecon will take the last hit -within the locally added file contexts! You can check the content of the -locally added rules in /etc/selinux/strict/contexts/files/file_contexts.local -(substitute strict with your SELinux type). -

- - -

-How do I make small changes (additions) to the policy? - - -

-If you are interested in the Gentoo Hardened SELinux development itself, please -have a look at the SELinux -Development Guide and other documentation linked from the SELinux project page. -

- -

-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. -

- -

-Updates on the policy are only possible as long as you need to allow -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 -fixlocal, substitute with whatever name you like - but keep it -consistent. In the file (fixlocal.te) put in the following text -(again, substitute fixlocal with your chosen name): -

- -

-policy_module(fixlocal, 1.0)
-
-require {
-# Declarations of types, classes and permissions used
-
-}
-
-# Declaration of policy rules
-

- -

-In this file, you can add rules as you like. In the next example, we add three -rules: -

- -

- Allow mozilla_t the execmem privilege (based on a denial that - occurs when mozilla fails to start) -
- Allow ssh_t to connect to any port rather than just the SSH port -
- Allows the user_t domain to send messages directly to the system - logger -

- -

-policy_module(fixlocal, 1.0)
-
-require {
-  type mozilla_t;
-  type ssh_t;
-  type user_t;
-
-  class process { execmem };
-}
-
-# Grant mozilla the execmem privilege
-allow mozilla_t self:process { execmem };
-
-# Allow SSH client to connect to any port (as provided by the user through the 
-# "ssh -p <portnum> ..." command)
-corenet_tcp_connect_all_ports(ssh_t)
-
-# Allow the user_t domain to send messages to the system logger
-logging_send_syslog_msg(user_t)
-

- -

-If you need to provide raw allow statements (like the one above for the -mozilla_t domain), make sure that the type (mozilla_t), -class (process) and privilege (execmem) are mentioned in -the require { ... } paragraph. -

- -

-When using interface names, make sure that the types (ssh_t and -user_t) are mentioned in the require { ... } paragraph. -

- -

-To find the proper interface name (like corenet_tcp_connect_all_ports -above), you can either look for it in the SELinux Reference Policy -API online or, if sec-policy/selinux-base-policy is built with the -doc USE flag, in /usr/share/doc/selinux-base-policy-.*/html. -Of course, you can also ask for help in #gentoo-hardened on -irc.freenode.net, the mailinglist, forums, etc. to find the proper rules and -statements for your case. -

- -

-With the policy file created, you can then build it using the -Makefile provided by the system: -

- -

-(This uses "strict" as the example policy type, substitute with your
-own)
-# make -f /usr/share/selinux/strict/include/Makefile fixlocal.pp
-

- -

-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. -

- -

-# semodule -i fixlocal.pp
-

- - -

- - - -SELinux Kernel Error Messages -

-I get a register_security error message when booting - - -

-During boot-up, the following message pops up: -

- -

-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
-

- -

-This is nothing to worry about (and perfectly normal). -

- -

-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. -

- - -

-I get a 'Permission ... in class ... not defined' message during booting - - -

-During boot-up, the following message is shown: -

- -

-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.
-

- -

-This means that the Linux kernel that you are booting supports permissions that -are not defined in the policy (as offered through the -sec-policy/selinux-base-policy 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). -

- - -

- - -SELinux and Gentoo -

-I get a missing SELinux module error when using emerge - - -

-When trying to use emerge, the following error message is displayed: -

- -

-!!! SELinux module not found. Please verify that it was installed.
-

- -

-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: -

- -

-~# rlpkg portage
-

- - -

-I get 'FEATURES variable contains unknown value(s): loadpolicy' - - -

-When running emerge, the following error is shown: -

- -

-FEATURES variable contains unknown value(s): loadpolicy
-

- -

-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. -

- -

-Please update your profile to a recent SELinux profile (one ending with -/selinux) and make sure that /etc/make.conf does not -have FEATURES="loadpolicy" set. -

- - -

-During rlpkg I get 'conflicting specifications for ... and ..., using ...' - - -

-When trying to relabel a package (rlpkg packagename) or system (rlpkg --a -r) you get a message similar to the following: -

- -

-filespec_add: conflicting specifications for /usr/bin/getconf and 
-/usr/lib64/misc/glibc/getconf/XBS5_LP64_OFF64, using
-system_u:object_r:lib_t
-

- -

-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. -

- -

-The solution depends on the particular case; in order of most likely to happen -and resolve: -

- -

- 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 (rm B; cp A B). This way, both - files have different inodes and can be labelled accordingly. -
- 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 /usr/lib64 location) using semanage - (semanage fcontext -a -t correct_domain_t /usr/lib64/path/to/file) -

- -

-It is also not a bad idea to report (after verifying if it hasn't been reported -first) this on Gentoo's bugzilla so -that the default policies are updated accordingly. -

- - -

-During package installation, ld.so complains 'object 'libsandbox.so' -from LD_PRELOAD cannot be preloaded: ignored' - - -

-During installation of a package, you might see the following error message: -

- -

->> 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.
-

- -

-This message should only occur after the Setting SELinux security -labels message. It happens because SELinux tells glibc to disable -LD_PRELOAD (and other environment variables that are considered -potentially harmful) during domain transitions. Here, portage calls the -setfiles command (part of a SELinux installation) and as such -transitions from portage_t to setfiles_t, which clears the environment -variable. -

- -

-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 libsandbox.so is not disabled during builds -and merges, only during the activity where Portage labels the files it -just merged. -

- -

-So the error is in our opinion cosmetic and can be ignored (but sadly not -hidden). -

- - -

-Emerge does not work, giving 'Permission denied: /etc/make.conf' - - -

-This is to be expected if you are not using the sysadm_r role. Any -Portage related activity requires that you are in the sysadm_r role. To -transition to the role, first validate if you are currently known as -staff_u (or, if you added your own SELinux identities, a user that has -the permission to transition to the sysadm_r role). Then run newrole --r sysadm_r to transition. -

- -

-~$ emerge --info
-Permission denied: '/etc/make.conf'
-~$ id -Z
-staff_u:staff_r:staff_t
-~$ newrole -r sysadm_r
-Password: # Enter your users' password
-

- -

-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. -

- - -

-Cron fails to load in root's crontab with message '(root) ENTRYPOINT -FAILED (crontabs/root)' - - -

-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: -

- -

-~# ls -Z /var/spool/cron/crontabs/root
-staff_u:object_r:user_cron_spool_t /var/spool/cron/crontabs/root
-

- -

-Next, check what the default context is for the given user (in this case, root) -when originating from the crond_t domain: -

- -

-~# getseuser root system_u:system_r:crond_t
-seuser:  root, level (null)
-Context 0       root:sysadm_r:cronjob_t
-Context 1       root:staff_r:cronjob_t
-

- -

-As you can see, the default context is always for the root SELinux user. -However, the /var/spool/cron/crontabs/root file context in the -above example is for the SELinux user staff_u. Hence, cron will not be able to -read this file (the user_cron_spool_t type is a UBAC constrained one). -

- -

-To fix this, change the user of the file to root: -

- -

-~# chcon -u root /var/spool/cron/crontabs/root
-

- -

-Another fix would be to disable UBAC completely. This is accomplished with -USE="-ubac". -

- - -

-When querying the policy, I get 'ERROR: could not find datum for type ...' - - -

-When using seinfo or sesearch to query the policy on the system, -you get errors similar to: -

- -

-~# seinfo -tasterisk_t
-ERROR: could not find datum for type asterisk_t
-

- -

-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: -

- -

-~# ls -ltr /etc/selinux/strict/policy/policy.*
-

- -

-The file modified last should be the same one as returned by checking -/selinux/policyvers: -

- -

-~# cat /selinux/policyvers; echo
-24
-

- -

-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: -

- -

-~# vim /etc/selinux/semanage.conf
-# Look for and uncomment the policy-version line and set it to the right version
-policy-version = 24
-

- - -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. - - - -

-Portage fails to label files because "setfiles" does not work anymore - - -

-Portage uses the setfiles 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 (libselinux.so, -libsepol.so, libaudit.so and of course -libc.so) might cause for the application to fail. Gentoo's standard -solution (revdep-rebuild) will not work, since the tool will try to -rebuild policycoreutils, which will fail to install because Portage cannot set -the file labels. -

- -

-The solution is to rebuild policycoreutils while disabling Portage's selinux -support, then label the installed files manually using chcon, based on -the feedback received from matchpathcon. -

- -

-# FEATURES="-selinux" emerge --oneshot policycoreutils
-# for FILE in $(qlist policycoreutils); do \
-CONTEXT=$(matchpathcon -n ${FILE}); chcon ${CONTEXT} ${FILE}; done
-

- -

-Now Portage will function properly again, labeling files as they should. -

- - -

-Applications do not transition on a nosuid-mounted partition - - -

-If you have file systems mounted with the nosuid option, then -applications started from these file systems will not transition into their -appropriate domain. This is intentional. -

- -

-So, a passwd binary, although correctly labeled passwd_exec_t, -will not transition into the passwd_t domain if the binary is stored on a -file system mounted with nosuid. -

- - -

-Why do I always need to re-authenticate when operating init scripts? - - -

-When you, as an administrator, wants to launch or stop daemons, these activities -need to be done as system_u:system_r. 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. -

- -

-You can ask not to re-authenticate if you use PAM by editing -/etc/pam.d/run_init and adding the following line on top: -

- -

-auth     sufficient     pam_rootok.so
-

- -

-With this in place, you can now prepend your init script activities with -run_init and it will not ask for your password anymore: -

- -

-# run_init rc-service local status
-Authenticating swift.
- * status: started
-

- - -

-How do I use SELinux with initramfs? - - -

-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 (setenforce 1). -

- -

-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 secure_mode_policyload boolean. -When enabled, enforcing mode cannot be disabled anymore (until you reboot). -

- -

-# setsebool secure_mode_policyload on
-

- - -

-Logons through xdm (or similar) fail - - -

-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. -

- -

-The reason of this is that PAM needs to be configured to include SELinux -awareness in your session handling: -

- -

-...
-session  required   pam_loginuid.so
-session  optional   pam_console.so
-session  optional   pam_selinux.so
-

- -

-Replicate the calls towards pam_selinux.so in the various -/etc/pam.d/gdm* files (or similar depending on your graphical -logon manager). -

- - -

-What is SELinuxfs and where should it be? - - -

-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. -

- -

-The file system is used by the SELinux utilities as an interface to query the -SELinux state, maintained by the Linux kernel. -

- -

-Historically (before libselinux-2.1.9), the mount point for the -SELinux file system had to be /selinux. From -libselinux-2.1.9 onwards, the default location where the file -system is looked for is /sys/fs/selinux, although the library still -falls back to the original /selinux location if it cannot find it -at the new place. -

- -

-However, the /sys/fs/selinux location currently has an issue for -those systems not using an initramfs, as it means that /sys has not -been mounted when init tries to mount /sys/fs/selinux. We -are working out how to resolve this, but for now, keep /selinux -active. -

- - -

- - 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 @@ - - - - - - - - - -6 -2012-04-29 - -

-Introduction - -SELinux Concepts - - -

-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 on top of 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. -

- -

-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. -

- - - - -SELinux Policies - - -

-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): -

- -

- targeted 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 - unconfined, meaning that there are little to no restrictions for - those processes. -
- strict is a policy where all processes are confined. There are no - unconfined domains. In other distributions, this is still considered the - targeted policy but without the unconfined domain definition. -
- multi-category security is a policy where the (confined) domains can - be categorized (split up), allowing for multiple processes running in - different instances of a confined domain -
- multi-level security 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. -

- -

-When using Gentoo Hardened, all these policies are available. However, -development focuses mainly on strict and mcs. The -targeted policy is assumed to work if strict works whereas we know -that the mls policy is currently not fit yet for production use. -

- - -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. - - - - -

-Security Contexts - -Users, Roles, Domains, Sensitivities and Categories - - -

-One of the first concepts you will need to be acquainted with is the concept of -a security context. 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. -

- -

-Within SELinux, such a security context is displayed using three to five -definitions, depending on the type of policy you are running: -

- -

user: - This is the SELinux user (which is not the same as the Linux/Unix - technical user) assigned to the resource -
role: - This is the SELinux role in which the resource currently works -
type: - This is the type assigned to the resource and is the key to SELinux' - enforcement rules -
sensitivity: - 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. -
category: - 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. -

- -

-More information on these particular definitions is given throughout the -remainder of this chapter. -

- - -

-As an example let's take a look at the security context of a logged on user: -

- -

-~$ id -Z
-staff_u:staff_r:staff_t
-

- -

-In this case, the user is identified as the SELinux user staff_u, -currently in the staff_r role and assigned to the staff_t -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 strict (or targeted) policy -system. The next example gives the same result, but on an MCS policy -system. -

- -

-~$ id -Z
-staff_u:staff_r:staff_t:s0-s0:c0.c1023
-

- -

-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 staff_u:staff_r:staff_t:s0. -

- - - - -Access Control Policy - - -

-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. -

- -

-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 object classes. Common examples are file or dir, -but SELinux also manages classes such as filesystem, tcp_socket, -process, sem (semaphores) and more. -

- -

-On each object class, a set of permissions is declared which are possible -against a resource within this object class. For instance, the process -object class supports at least the following permissions: -

- -

-~# ls /selinux/class/process/perms
-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
-

- -

-The most common SELinux access control rule (allow) is described as -follows: -

- -

-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")
-

- -

-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 staff_u:staff_r:staff_t -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. -

- -

-(Show the security context for the users' home directory)
-~$ ls -dZ ${HOME}
-staff_u:object_r:user_home_dir_t  /home/swift
-
-(Find the allow-rule which allows the staff_t type to write into a 
- directory with the user_home_dir_t type)
-~$ sesearch -s staff_t -t user_home_dir_t -c dir -p write -A
-Found 1 semantic av rules:
-  allow staff_t user_home_dir_t : dir { ioctl read write create ... };
-

- -

-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 domain 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 object_r role by SELinux. -

- -

-Now take a look at the following example. Our user, who is inside the portage -group, wants to write to the /var/tmp/portage directory: -

- -

-~$ id -a
-uid=1001(swift) gid=100(users) groups=100(users),...,250(portage),...
-~$ ls -ldZ /var/tmp/portage
-drwxrwxr-x. 3 portage portage  system_u:object_r:portage_tmp_t 4096 Dec  6 21:08 /var/tmp/portage
-

- -

-From the standard Linux permissions, the user has write access. But does SELinux -also grant it? -

- -

-~$ sesearch -s staff_t -t portage_tmp_t -c dir -p write -A
-~$ 
-(Notice that there is no output given here)
-~$ touch /var/tmp/portage/foo
-touch: cannot touch '/var/tmp/portage/foo': Permission denied
-

- -

-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. -

- - - -

-Type Enforcements / Domain Types - -Types and Domains - - -

-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 -type) and work our way forward through the roles and users. -

- -

- A SELinux type is a particular label assigned to a resource. The - passwd command for instance is labeled with the passwd_exec_t type. -
- A SELinux domain 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 passwd command, its domain is passwd_t. -

- -

-The rules that identify the allowed actions for a domain have been described earlier. Again: -

- -

-allow <src_domain> <dst_type> : <class> { permission [ permission [ ... ] ] } ;
-

- -

-An example for the passwd_t domain would be the permissions granted -between the passwd_t domain and the shadow_t type (used by the -/etc/shadow file). -

- -

-allow passwd_t shadow_t : file { ioctl read write create ... } ;
-

- -

-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. -

- -

-To support easier grant rules, SELinux allows grouping of types using type -attributes. For instance, the attribute exec_type bundles all types -that are assigned to executable files (such as bin_t, ssh_exec_t, -...), whereas the file_type 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. -

- - - - -Domain Transitions - - -

-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 passwd command would automatically bring the -process in the passwd_t domain), but this is in fact a combination of -three specific privileges that need to be granted: -

- -

- The current domain must be allowed to transition to a domain -
- The target domain should have an entry point, which is an executable - that is allowed to start in the domain -
- The source domain should have execute rights on (the domain of) that - executable -

- - -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. - - -

-Through these rules, the security administrator of a system can more -specifically control who and under which conditions particular actions can be -taken. -

- - - -

-Roles and Rights - -The Role of a Role - - -

-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? -

- -

-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 ifconfig_t 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 user_r to be assigned with the -ifconfig_t domain. -

- -

-~$ seinfo -ruser_r -x
-  user_r
-    Dominated Roles:
-      user_r
-    Types:
-      ...
-~$ seinfo -rsysadm_r -x
-  sysadm_r
-    Dominated Roles:
-      sysadm_r
-    Types:
-      ...
-      ifconfig_t
-      ...
-

- - -Again, not being able to be associated with a domain does not mean that the -user_r role cannot execute the ifconfig binary. It can, but -it will execute the binary within its own domain (user_t) 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). - - -

-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. -

- -

-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. -

- - - - -Role Transitions - - -

-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: -

- -

object_r: - The object_r 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). -
system_r: - The system_r role is used for highly privileged system services. - The system_r role is allowed to switch to any other "default" role. - No role exception sysadm_r can switch to the system_r role. -
sysadm_r: - The sysadm_r role is used for system administration activities. The - sysadm_r role is allowed to switch to any other "default" role. Only - the system_r and staff_r roles are allowed to switch to the - sysadm_r role. -
staff_r: - The staff_r role is used for system operators who might have the - rights to perform system administration tasks. The staff_r role is - only allowed to switch to the sysadm_r role. Only sysadm_r and - system_r can switch to the staff_r role. -
user_r: - The user_r role is used for standard, unprivileged users. It is not - allowed to transition towards any other role; only sysadm_r and - system_r roles are allowed to switch to the user_r role. -

- - -A "default" role is any of user_r, staff_r, sysadm_r or -system_r. If you create additional roles yourself, they are not part of -the "default" roles. - - -

-Using these definitions, a user inside the user_r role will never be able -to execute ifconfig within the ifconfig_t domain. The use of the -word never here is important: not even if the user is able to become -root using sudo or any other command will he be able to run the -ifconfig command in the ifconfig_t domain because, even after -running sudo, he is still inside the user_r role. -

- - - - -SELinux Users - - -

-A SELinux user is not the same as the Linux user. Whereas standard Linux user -accounts can be switched using commands such as su or sudo, a -SELinux user can not be changed. Even when you successfully execute sudo, -your SELinux user will remain the same. -

- -

-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 root, user_u, staff_u, sysadm_u and -system_u 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? -

- -

-Well, no. SELinux users are also used to categorize accounts which have the -permission to use a particular role. -

- -

-~# semanage user -l
-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
-

- -

-Standard Linux users are mapped to these SELinux users: -

- -

-~# semanage login -l
-Login Name          SELinux User
-
-__default__         user_u
-root                root
-swift               staff_u
-

- -

-In this example, only logins of the Linux user swift (through -staff_u) and root (through the root SELinux user) -will be able to eventually run inside the sysadm_r role. All other -Linux accounts will be by default mapped to the user_u user (and -this user_r role). -

- -

-This is only applicable for interactive logins. Processes that are -launched through an init script or otherwise do not automatically become part of -the SELinux user user_u: 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 user_u:user_r:user_t then -they will not be able to transform into anything other than -user_u:user_r:* with * a domain supported by the user_r -role. -

- -

-SELinux users are also used to implement User Based Access Control or -UBAC. 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. -

- -

-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 ubac USE flag. -

- - - -

-Multi Level Security / Multi Category Security - -Introduction - - -

-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. -

- -

-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. -

- - - - -Multi-Level Security - - -

-The most flexible - but also most challenging to manage - method offered by -SELinux is MLS, or Multi-Level Security. 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. -

- -

-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", ... -

- -

-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. -

- - - - -Multi-Category Security - - -

-The MCS or Multi-Category Security policy is a subset of the MLS policy. -It supports the various categories, but without using the multiple security -levels for the resources. -

- -

-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 multitenancy -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). -

- - - -

- -

-Reference Policy - -About refpolicy - - -

-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. -

- -

-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. -

- -

-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 The Reference Policy. -

- -

-This project, managed by Tresys, 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. -

- - - - -Reference Policy API - - -

-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 online, but if you have -USE="doc" set, it will be stored on your system as well the moment you install -and configure SELinux. -

- - - - -Modular Approach - - -

-Another feature of the reference policy is its use of modules. 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. -

- -

-Instead, the reference policy defines the rules in what it calls modules, which -define one domain (like portage_t) 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. -

- -

-# semodule -l
-alsa    1.11.0
-apache  2.3.0
-audioentropy    1.6.0
-dbus    1.15.0
-dmidecode       1.4.0
-(...)
-

- -

-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). -

- - - - -Tunables and Conditionals - - -

-But wait, there's more. The reference policy also supports booleans. -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. -

- -

-# getsebool -a
-allow_execheap --> off
-allow_execmem --> off
-allow_execmod --> off
-allow_execstack --> off
-allow_gssd_read_tmp --> on
-allow_httpd_anon_write --> off
-

- -

-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. -

- - - - -Policy Files and Versions - - -

-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). -

- -

-# sestatus
-SELinux status:                 enabled
-SELinuxfs mount:                /selinux
-Current mode:                   enforcing
-Mode from config file:          enforcing
-Policy version:                 24
-Policy from config file:        strict
-

- -

-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. -

- -

Version 12: "Old API" for SELinux, which is now deprecated
Version 15: "New API" for SELinux, merged in Linux kernel 2.6.0 (until 2.6.5)
Version 16: Conditional policy extensions added (2.6.5)
Version 17: IPV6 support added (2.6.6 - 2.6.7)
Version 18: Fine-grained netlink socket support added (2.6.8 - 2.6.11)
Version 19: Enhanced multi-level security (2.6.12 - 2.6.13)
Version 20: Access vector table size optimizations (2.6.14 - 2.6.18)
Version 21: Object classes in range transitions (2.6.19 - 2.6.24)
Version 22: Policy capabilities (features) (2.6.25)
Version 23: Per-domain permissive mode (2.6.26 - 2.6.27)
Version 24: Explicit hierarchy (type bounds) (2.6.28 - 2.6.38)
Version 25: Filename based transition support (2.6.39)
Version 26: Role transition support for non-process classes (3.0)

- - - - -

- -

-Next Steps - -What Next - - -

-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. -

- -

-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. -

- - - -

- 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 @@ - - - - - - - - - -2 -2011-05-25 - -

-Introduction - -A Warm Welcome - - -

-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. -

- -

-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. -

- - - -

-Securing Linux - -Security In General - - -

-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? -

- -

-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. -

- -

-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". -

- -

-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. -

- - - - - -Access Control - - -

-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. -

- -

-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. -

- -

-Authenticating users within Linux is often done through PAM (Pluggable -Authentication Modules), a powerful mechanism to integrate multiple -low-level authentication schemes into a high-level interface. -

- -

-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. -

- -

-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). -

- -

-Another drawback is that the permission scheme is discretionary, meaning -that users and processes are able to change the security policy in place. -

- -

-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. -

- - - -

-Mandatory Access Control - -Enter SELinux - - -

-If the above mentioned discretionary access control, abbreviated to DAC, -is not sufficient (and if you are keen on security, you will not find it -sufficient), you need a Mandatory Access Control, or MAC system. -

- -

-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. -

- -

-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. -

- -

-SELinux also allows you to put a finer-grained permission model on top -of 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). -

- - - - -What is SELinux - - -

-To support this finer-grained permission model, you would think that changes -are needed to the Linux kernel. Yet thanks to the Linux kernel LSM -interface (Linux Security Modules), 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. -

- -

-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 extended attributes, -which not all file systems do (or have activated). -

- -

-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. -

- -

-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 sudo), 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. -

- - - - -Gentoo Hardened and SELinux - - -

-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. -

- -

-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 -#gentoo-hardened chat channel in the Freenode IRC network or on our -mailing lists. -

- -

-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. -

- - - -

- 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 @@ - - - - - - - - - -1 -2011-06-02 - -

-About SELinux Policies - -SELinux Policy Language - - -

- -

-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: -

- -

-allow user_t bin_t:file { read execute open };
-

- -

-Other supported rules are -

- -

- dontaudit will disable the logging of the denial message(s) -
- auditallow will allow the access but will also log it (by default, - allowances are not logged) -
- neverallow 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. -

- -

-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 -reference policy has been brought to life with the following required -functionalities: -

- -

- development of SELinux policy rules should be centralized even for different - distributions -
- a macro language should be supported that makes it easier to write new - policies -
- the policies should be modular, allowing for additional rules to be added or - removed -

- -

-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. -

- - - - -Tresys Reference Policy - - -

-The reference policy by choice is the Tresys SELinux Reference -Policy. 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. -

- -

-The reference policy starts off with a base policy called -base.pp. 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 selinux-base-policy. -

- -

-The policy modules themselves also use the .pp extension, but are -named more appropriately towards their content. For instance, the policy module -that contains all policy rules for the screen application is called -screen.pp. However, don't count on all policy modules to be named -after the tool: the policy module that contains the wpa_supplicant -specific rules is called networkmanager.pp. In Gentoo Hardened, the -modular policies are available in the sec-policy category and are -named selinux-<module>. -

- -

-To get a list of running modules, run semodule: -

- -

-~# semodule -l
-dbus    1.14.0
-dnsmasq 1.9.0
-hal     1.13.0
-[...]
-

- - - - -Toggle Policy States - - -

-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 SELinux -booleans. -

- -

-SELinux booleans allow for rules to be conditionally applied, based on the -administrator's requirements. You can get a list of supported booleans through -getsebool: -

- -

-~# getsebool -a
-allow_execheap --> off
-allow_execmem --> off
-[...]
-fcron_crond --> off
-global_ssp --> on
-[...]
-

- -

-If you need to change a boolean, you can use togglesebool to switch its -value, or setsebool so explicitly set its state: -

- -

-~# getsebool user_dmesg
-user_dmesg --> off
-~# togglesebool user_dmesg
-user_dmesg: active 
-(Now, the state is set to 'on')
-~# getsebool user_dmesg
-user_dmesg --> on
-(Explicitly set the value to 'off')
-~# setsebool user_dmesg off
-

- - - - -Policy Files and Locations - - -

-On Gentoo Hardened, the SELinux policy files are stored in -/usr/share/selinux/strict or -/usr/share/selinux/targeted (depending on your SELinux -configuration). Within this location, you will find: -

- -

- a file called base.pp, which is the SELinux base policy, -
- one or more files with extension .pp, which are the SELinux - policy modules, and -
- an include/ folder which contains the necessary files for - SELinux module developers to build additional modules for this system -

- - - - -Policy Versions - - -

-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 -sestatus 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. -

- -

Version 12: "Old API" for SELinux, which is now deprecated
Version 15: "New API" for SELinux, merged in Linux kernel 2.6.0 (until 2.6.5)
Version 16: Conditional policy extensions added (2.6.5)
Version 17: IPV6 support added (2.6.6 - 2.6.7)
Version 18: Fine-grained netlink socket support added (2.6.8 - 2.6.11)
Version 19: Enhanced multi-level security (2.6.12 - 2.6.13)
Version 20: Access vector table size optimizations (2.6.14 - 2.6.18)
Version 21: Object classes in range transitions (2.6.19 - 2.6.24)
Version 22: Policy capabilities (features) (2.6.25)
Version 23: Per-domain permissive mode (2.6.26 - 2.6.27)
Version 24: Explicit hierarchy (type bounds) (2.6.28 - 2.6.38)
Version 25: Filename based transition support (2.6.39)
Version 26: Role transition support for non-process classes (3.0)

- - - -

- 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 @@ - - - - - - - - - -2 -2011-05-31 - -

-Background - -Introduction to SELinux - - -

- The Inevitability of Failure: - The Flawed Assumption of Security in Modern Computing Environments - explains the need for mandatory access controls. -
- The Flask Security Architecture: - System Support for Diverse Security Policies - explains the security architecture of Flask, the architecture used by SELinux. -
- Implementing SELinux as a Linux Security Module - has specifics about SELinux access checks in the kernel. -

- - - -

-SELinux Policy - -Policy Related References - - -

- Configuring the SELinux Policy -
- SELinux Reference Policy -
- SELinux Object Classes and Permissions Overview -

- - - -

-Books - -Paper Books - - -

- SELinux by Example: Using Security Enhanced Linux, Frank Mayer, - Karl MacMillan, and David Caplan, Prentice Hall, 2006; ISBN 0131963694 -
- SELinux: NSA's Open Source Security Enhanced Linux, Bill McCarty, - O'Reilly Media, 2004; ISBN 0596007167 -

- - - -

- -

-Gentoo Specific Resources - -Gentoo Hardened - - -

-The following resources are specific towards Gentoo Hardened's SELinux -implementation. -

- -

- SELinux Frequently Asked - Questions -

- - - -

- 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 @@ - - - - - - - - - -0 -2010-12-01 - -

-TODO - - - -

-This is a place-holder for future expansion. -

- - - -

- 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 @@ - - - - - - - - - -6 -2011-10-15 - -

-SELinux Information Commands - -Introduction - - -

-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. -

- -

-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.) -

- - - - -Getting SELinux Status - - -

-The first command we will talk about is sestatus. -

- -

-# sestatus
-SELinux status:                 enabled
-SELinuxfs mount:                /selinux
-Current mode:                   permissive
-Mode from config file:          permissive
-Policy version:                 24
-Policy from config file:        strict
-

- -

-The output of this command shows you that SELinux is enabled and is currently in -the permissive mode. It also tells you that the system is configured to -run in strict mode - so no unconfined_t domain here. -

- -

-The sestatus command also has an extended output if you run it with the --v option. When this is done, the command returns the contexts of -important processes and files: -

- -

-# sestatus -v
-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
-

- -

-Another general SELinux status command is getenforce, 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). -

- -

-# getenforce
-Enforcing
-

- - - - -Getting SELinux Object Information - - -

-Next on the table is the seinfo command. This command allows you to query -the running policy for all objects (types, roles, attributes, users, booleans -...) defined. -

- -

-Common usages are: -

- -

- 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) -
- 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) -
- 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 -

- -

-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. -

- -

-# seinfo -tcrontab_t
-  crontab_t
-# seinfo -ruser_r -x
-  user_r
-    Dominated Roles:
-      user_r
-    Types:
-      [...]
-      crontab_t
-      [...]
-# seinfo -acron_spool_type -x
-  cron_spool_type
-    user_cron_spool_t
-    system_cron_spool_t
-

- - - - -Querying SELinux Policy Rules - - -

-A command which you will often use is sesearch. 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). -

- -

-The sesearch command is most often used with a source domain (-s), -target domain (-t) 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 ...). -

- -

-For instance, to find out which domains can write the files that have the -shadow_t domain: -

- -

-# sesearch -t shadow_t -c file -p write -A
-Found 8 semantic av rules:
-  [...]
-  allow portage_t shadow_t : file { ioctl read write ... };
-  allow useradd_t shadow_t : file { ioctl read write ... };
-  ...
-

- -

-You will notice that there are sometimes results based on attributes rather than -domains: -

- -

-  allow portage_t file_type : file { ioctl read write ... };
-

- -

-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: -

- -

-# sesearch -t file_type -c file -p write -A -d
-Found 1 semantic av rules:
-  allow portage_t file_type : file { ioctl read write ... };
-

- -

-Note that we had one command without the -d option and one with. When --d is given, the search will perform an exact search without resolving -the attributes. When -d is not given, it will resolve the attribute. In -the last command example, dropping -d 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. -

- -

-Another interesting functionality of the sesearch 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 -b. If you want to see the logic -that the policy uses, use -C (and yes, both can be combined). -

- -

-As an example, we'll check what we allow (or deny) when the global_ssp -boolean is set: -

- -

-# sesearch -b global_ssp -A -C -d
-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 ]
-

- -

-The prefix you see shows two letters, relating to two important definitions: -

- -

- Is the rule currently Enabled or Disabled? -
- Does the boolean need to be set to True or False to enable the rule? -

- - - - -Getting Security Context Information - - -

-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. -

- -

-To get the security context of a file, use ls -Z: -

- -

-~$ ls -Z /etc/make.conf
-system_u:object_r:portage_conf_t /etc/make.conf
-

- -

-To get the security context of a process, use ps -Z: -

- -

-# ps -Z $(pidof init)
-LABEL                             PID TTY      STAT   TIME COMMAND
-system_u:system_r:init_t            1 ?        Ss     0:00 init [3]  
-

- -

-To get the security context of the current user, use id -Z: -

- -

-~$ id -Z
-staff_u:staff_r:staff_t
-

- - - -

-Managing SELinux - -Introduction - - -

-Managing SELinux objects (booleans, users, ports, contexts ...) is most often -done using semanage. 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). -

- - - - -Booleans - - -

-We have already covered SELinux booleans earlier in this book as well as the -getsebool and setsebool commands. With semanage 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). -

- -

-# semanage boolean -l
-SELinux boolean                 Description
-
-allow_ptrace            -> off  allow_ptrace
-rsync_export_all_ro     -> off  rsync_export_all_ro
-

- - -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. - - -

-You can set a boolean with both setsebool and semanage: -

- -

-# semanage boolean -m --on -F user_dmesg
-

- - - - -SELinux Users and Logins - - -

-SELinux users and logins are different from Unix accounts. SELinux logins allow -you to map a Unix account to a SELinux user: -

- -

-# semanage login -l
-Login Name          SELinux User
-
-__default__         user_u
-root                root
-swift               staff_u
-system_u            system_u
-

- -

-The default behavior is that users are logged on as the user_u 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 su or sudo rights for anything). -

- -

-The account you use to administer your system should be mapped to the -staff_u SELinux user (or its own user with the appropriate roles). This -can be accomplished as follows (example with the Unix account anna): -

- -

-# semanage login -a -s staff_u anna
-

- - -Make sure that whatever account you use to administer your system is mapped to -the staff_u user, or has the ability to switch to the sysadm_r -role. Portage only works from within the sysadm_r role. - - -

-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 semanage user -l: -

- -

-# semanage user -l
-SELinux User        SELinux Roles
-
-root                staff_r sysadm_r
-staff_u             staff_r sysadm_r
-[...]
-

- - - - -Managing Ports - - -

-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 -semanage port -l. -

- -

-# semanage port -l | grep '22$'
-ssh_port_t             tcp     22
-

- - - -

- -

-Using SELinux - -Introduction - - -

-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. -

- - - - -Switching Roles - - -

-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. -

- -

-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 SELinux Users and Logins). -

- -

-The command that accomplishes switching roles is called newrole. It's -use is pretty straight forward. -

- -

-~$ newrole -r sysadm_r
-Password: (Enter the users' password - not root's!)
-

- -

-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 -su or sudo to become the root user, then newrole will still -require you to enter the regular users' password. -

- - - -

- - 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 @@ - - - - - - - - - -1 -2011-09-30 - -

-Administering Users - -Introduction - - -

-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 sudo, the SELinux policy will not allow -this user to do anything that is administration related. -

- -

-For this reason, it is important to go over the SELinux user mappings and the -Linux users on your system. -

- - - - -User Mappings - - -

-Run semanage login -l to show the current mappings between Linux logins -and SELinux users. -

- -

-# semanage login -l
-
-Login Name                SELinux User
-
-__default__               user_u
-root                      root
-john                      staff_u
-system_u                  system_u
-

- -

-The "user_u" SELinux user is for regular accounts. As such, the special -__default__ 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. -

- -

-The next table gives an overview of the standard SELinux users available after -an installation. -

- - - - - - - - user_u - - Default regular SELinux user, which should be used by end-user accounts that - are not going to administer any service(s) on the system - - - - staff_u - - SELinux user for administrators. This user has the right to switch roles and - as such gain elevated privileges - - - - root - - 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 - - - - sysadm_u - - 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). - - - - system_u - - 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) - - - - unconfined_u - - Used when the policy is targeted, 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). - - -

SELinux User	Description

- -

-To map a user to a specific SELinux user, use semanage login -a: -

- -

-# semanage login -a -s staff_u sophie
-

- -

-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: -

- -

-# restorecon -R -F /home/sophie
-

- - - - -Additional SELinux Accounts - - -

-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). -

- -

-Managing the SELinux accounts is done through semanage user: -

- -

-# semanage user -a -R "staff_r sysadm_r" sophie
-

- -

-Let's verify how the SELinux users are currently configured: -

- -

-# semanage user -l
-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
-
-# semanage login -l
-Login Name                SELinux User
-
-__default__               user_u
-root                      root
-sophie                    staff_u
-swift                     staff_u
-system_u                  system_u
-

- -

-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": -

- -

-# semanage login -m -s sophie sophie
-# semanage login -l
-Login Name                SELinux User
-
-__default__               user_u
-root                      root
-sophie                    sophie
-swift                     staff_u
-system_u                  system_u
-

- -

-Again, do not forget to relabel this users' files. -

- -

-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 SELinux Concepts, but as roles are -important when using a Mandatory Access Control system, let's refresh our memory -again: -

- - - - - - - - user_r - - 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. - - - - staff_r - - 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 - - - - sysadm_r - - 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) - - - - system_r - - System service role, which is used for the runtime services (processes). It - is never granted to users directly. - - - - unconfined_r - - The unconfined role is used when the targeted 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). - - -

SELinux Role	Description

- -

-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. -

- - - -

- -

-Reading Audit Logs - -Introduction - - -

-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 permission -denied error message. -

- -

-Initially, SELinux is running in permissive mode, which means that -SELinux will log what it would 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 permissive to -enforcing. We'll talk about these modes later. -

- -

-First, let's take a look at the audit log and see what it is saying... -

- - - - -Audit Log Location(s) - - -

-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 syslog-ng system logger, then the logger is already -configured to place these audit lines in /var/log/avc.log. However, -different system loggers or system logger configurations might put the entries -in a different log location (such as /var/log/audit.log). -

- -

-Below, you'll find the appropriate lines for the syslog-ng system logger -configuration for writing the events in /var/log/avc.log. -

- -

-# The following lines are only /part/ of the configuration file!
-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);
-};
-

- - - - -What is AVC? - - -

-As we mentioned, SELinux writes its entries in the audit log. These entries are -called avc messages or avc log entries. The abbreviation AVC -stands for Access Vector Cache and, like the name sais, is a caching -system. -

- -

-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. -

- - - - -Reading an AVC Denial Message - - -

-Below you'll find a typical 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
-

- -

-Let's analyze each part of this message one by one. -

- -

-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
-

- -

-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). -

- -

-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
-

- -

-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. -

- -

-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
-

- -

-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 -

- -

-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
-

- -

-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. -

- -

-For instance, in the following case, a process gorg with PID 13935 is -trying to read a file called localtime with inode 130867 which -resides on the device /dev/md3: -

- -

-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
-

- -

-In this case, it might be obvious that the file is /etc/localtime, -but when that isn't the case, then you can find the following two commands -useful: -

- -

-(Find out which device /dev/md3 is)
-# mount | grep /dev/md3
-/dev/md3 on / type ext4 (rw,seclabel,noatime,barrier=1,nodelalloc,data=journal)
-
-(Find out what file has inode 130867)
-# find / -xdev -inum 130867
-/etc/localtime
-

- - - - -Handling AVC denials - - -

-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. -

- -

-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 dontaudit, 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 dontaudit rules: -

- -

-(The command can also be abbreviated to "semodule -DB")
-# semodule --build --disable_dontaudit
-

- -

-In most cases though, denials need to be acted upon. Actions that might need to -happen are: -

- -

- relabeling the target resource (wrong labels might cause legitimate actions - to be denied) -
- relabeling the source (process' binary file) as a wrong label might cause - the application to run in the wrong domain -
- 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) -
- 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. -
- adding your own SELinux policy statements, most likely because no SELinux - policy module exists for the application you are trying to run -

- - - -

- -

-Using (File) Labels - -Introduction - - -

-Within SELinux, access privileges are based on the label given on the -originating part (called the domain) and its target resource. For -instance, a process running in the passwd_t domain wants to read (= privilege) -the file /etc/shadow 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). -

- - - - -Getting File Label(s) - - -

-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). -

- -

-In SELinux, labels are given on a file level through the file systems' ability -to keep extended attributes. For SELinux, the attribute is called -security.selinux and can be obtained through getfattr: -

- -

-$ getfattr -n security.selinux /etc/hosts
-# file: etc/hosts
-security.selinux="system_u:object_r:net_conf_t"
-

- -

-Of course, getting the file attribute this way is time consuming and not that -flexible. For this purpose, most important applications (including -coreutils) are made SELinux-aware. These applications mostly use the --Z option to display the SELinux context information. In case of files, -this means the extended attribute content: -

- -

-$ ls -Z /etc/hosts
-system_u:object_r:net_conf_t   /etc/hosts
-

- -

-Other commands exist that display the context as it should be, like -matchpathcon. 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: -

- -

-$ ls -Z /etc/make.conf
-staff_u:object_r:etc_t    /etc/make.conf
-$ matchpathcon /etc/make.conf
-/etc/make.conf            system_u:object_r:portage_conf_t
-

- - - - -Setting File Label(s) - - -

-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 -(relabelfrom) and to which labels are you allowed to change -(relabelto). You can query these rules through sesearch: -

- -

-# From which label on files (-c) is user_t (-s) allowed (-A) to relabel from (-p)?
-$ sesearch -s user_t -c file -p relabelfrom -A
-[...]
-allow user_t mozilla_home_t : file { ... relabelfrom relabelto } ;
-

- -

-If you have the permission, then you can use chcon to change the -context of a file: -

- -

-$ ls -Z strace.log
-staff_u:object_r:user_home_t  strace.log
-$ chcon -t mutt_home_t strace.log
-$ ls -Z strace.log
-staff_u:object_r:mutt_home_t  strace.log
-

- -

-If you do not hold the right privileges, you will get a descriptive error -message: -

- -

-$ chcon -t shadow_t strace.log
-chcon: failed to change context of `strace.log' to `staff_u:object_r:shadow_t': Permission denied
-

- -

-Now, if you now think that chcon is all you need, you're wrong. The -chcon 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). -

- -

-We will look at SELinux policy modules later, but below you'll find an excerpt -from such a definition, for the mozilla module: -

- -

-/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)
-

- -

-To put the right label on a file, you can use the setfiles or -restorecon commands. Since they are both the same command (but with a -slightly different way of using) we'll only talk about restorecon for now -- more information on the setfiles command can be found in its man page. -

- -

-When you use restorecon, 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, -restorecon supports recursivity, so you do not need to relabel files one -by one. -

- -

-$ ls -Z /etc/make.conf
-staff_u:object_r:etc_t            /etc/make.conf
-$ restorecon /etc/make.conf
-$ ls -Z /etc/make.conf
-system_u:object_r:portage_conf_t  /etc/make.conf
-

- -

-Finally, Gentoo also provides a useful application: rlpkg. This script -relabels the files of a Gentoo package (rlpkg <packagename>) or, -given the right arguments, all files on the file system: -

- -

-# Relabel the files of the firefox-bin package:
-# rlpkg firefox
-
-# Relabel all files on the file system:
-# rlpkg -a -r
-

- - - - -Overriding the SELinux Policy File Labels - - -

-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 chcon 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 -restorecon as well and override the rules provided by the SELinux policy. -

- -

-To add additional file context rules, you need to use the semanage -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 semanage -fcontext command: -

- -

-# Mark /mnt/gentoo/etc/make.conf as a portage_conf_t type
-# semanage fcontext -a -t portage_conf_t /mnt/gentoo/etc/make.conf
-
-# Mark /mnt/gentoo/usr/portage as portage_ebuild_t
-# semanage fcontext -a -t portage_ebuild_t "/mnt/gentoo/usr/portage(/.*)?"
-

- -

-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 FAQ on "How do -I know which file context rule is used for a particular file?." -

- -

-If you want to delete a file context definition, you use semanage fcontext --d: -

- -

-# semanage fcontext -d -t portage_ebuild_t /mnt/gentoo/etc/make.conf
-

- -

-Finally, to view all file context definitions (both user-set and SELinux policy -provided), you can use semanage fcontext -l. To only see the locally set, -add -C: -

- -

-# semanage fcontext -C -l
-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
-

- - - - -Customizable types - - -

-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. -

- -

-A customizable type 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 restorecon -F). -

- -

-There are not that many customizable types by default. The list of types that -SELinux considers as customizable are mentioned in the -customizable_types file within the -/etc/selinux/*/contexts location: -

- -

-# cat /etc/selinux/strict/contexts/customizable_types
-mount_loopback_t
-public_content_rw_t
-public_content_t
-swapfile_t
-textrel_shlib_t
-

- -

-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 public_content_t 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. -

- -

-If you look at the restorecon 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 mozilla policy 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)
-

- -

-Although in the above example, forcing restorecon 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 mozilla_home_t. If you want to download something, -this isn't possible (unless you download it into ~/.mozilla). The -solution there is to label a directory (say ~/Downloads) as -mozilla_home_t. -

- - - -

- -

-SELinux Policy and Booleans - -Introduction - - -

-We have dealt with users and labels now, but there is still a third aspect that -we haven't touched: the SELinux policy itself. -

- -

-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. -

- - - - -Changing the SELinux Policy Behavior: Booleans - - -

-A common and user friendly way of tweaking the SELinux policy is through -booleans. A SELinux boolean, 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: -

- -

-# getsebool -a | grep ^user
-user_direct_mouse --> off
-user_dmesg --> off
-user_ping --> on
-user_rw_noexattrfile --> off
-user_tcp_server --> off
-user_ttyfile_stat --> off
-

- -

-Although they might not say much on first sight, these booleans alter how the -SELinux policy enforces user activity (hence the booleans starting with -user_). For instance, user_ping is set to on, so a -user is allowed to use ping. If it was set to off, the SELinux -policy would not allow a user to execute ping. -

- -

-Booleans can be toggled on or off using setsebool or togglesebool. -With setsebool you need to give the value (on or off) whereas -togglesebool switches the value. -

- -

-# setsebool user_ping off
-

- -

-By default, setsebool does not store the boolean values - after a reboot, -the old values are used again. To persist such changes, you need to add the --P option: -

- -

-# setsebool -P user_dmesg on
-

- -

-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. -

- - - - -Managing SELinux Policy Modules - - -

-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). -

- -

-With semodule -l you can see the list of SELinux policy modules loaded: -

- -

-# semodule -l
-alsa       1.11.0
-apache     2.3.0
-entropyd   1.6.0
-dbus       1.15.0
-dnsmasq    1.9.0
-(...)
-

- -

-Within Gentoo Hardened, each module is provided by the package -sec-policy/selinux-<modulename>. For instance, the first -module encountered in the above example is provided by -selinux-alsa: -

- -

-$ emerge --search selinux-alsa
-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
-

- -

-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: -

- -

-# emerge selinux-screen
-

- -

-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: -

- -

-# emerge -C selinux-screen
-# semodule -r screen
-

- - - -

- 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 @@ - - - - - - - - - -24 -2012-05-07 - -

-Installing Gentoo (Hardened) - -Introduction - - -

-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). -

- -

-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. -

- - - - -Performing a Standard Installation - - -

-Install Gentoo Linux according to the Gentoo -Handbook installation instructions. We recommend the use of the hardened -stage 3 tarballs and hardened-sources 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. -

- - -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 -mkfs.xfs command with the -i size=512 arguments, like so: -mkfs.xfs -i size=512 /dev/sda3 - - - - - - - -Switching to Python 2 - - -

-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. -

- -

-~# emerge '<=dev-lang/python-3.0'
-~# eselect python list
-Available Python interpreters:
-  [1]   python2.7
-  [2]   python3.1 *
-
-~# eselect python set 1
-~# source /etc/profile
-

- - - - -Optional: Setting the filesystem contexts - - -

-If your /tmp location is a tmpfs-mounted file system, then you need -to tell the kernel that the root context of this location is tmp_t -instead of tmpfs_t. Many SELinux policy objects (including various -server-level policies) assume that /tmp is tmp_t. -

- -

-To configure the /tmp mount, edit your /etc/fstab: -

- -

-# For a "targeted" or "strict" policy type:
-tmpfs  /tmp  tmpfs  defaults,noexec,nosuid,rootcontext=system_u:object_r:tmp_t  0 0
-
-# For an "mls" or "mcs" policy type:
-tmpfs  /tmp  tmpfs  defaults,noexec,nosuid,rootcontext=system_u:object_r:tmp_t:s0  0 0
-

- - - - - -Change the Gentoo Profile - - -

-Now that you have a running Gentoo Linux installation, switch the Gentoo profile -to the right SELinux profile (for instance, -hardened/linux/amd64/no-multilib/selinux). Note that the older -profiles (like selinux/v2refpolicy/amd64/hardened) are not -supported anymore. -

- -

-~# eselect profile list
-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
-
-~# eselect profile set 12
-

- - -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. - - -

-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. -

- - - - -Update make.conf - - -

-Next, take a look at the following USE flags and decide if you want to enable -or disable them. -

- - - - - - - - - peer_perms - Enabled - - 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. - - - - open_perms - Enabled - - 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. - - - - ubac - Enabled - - When disabled, the SELinux policy is built without user-based access control. - - -

USE flag	Default Value	Description

- -

-Make your choice and update the USE variable in -/etc/make.conf. -

- - - - -Manual System Changes - - - -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). - - -

-The following changes might be necessary on your system, depending on the -tools or configurations that apply. -

- -

- Check if you have *.old files in /bin. If you do, - either remove those or make them a copy of their counterpart so that they - get their own security context. The .old files are hard links - which mess up the file labelling. For instance, cp /bin/hostname - /bin/hostname.old. -
- Edit /etc/sandbox.conf and add in - SANDBOX_WRITE="/sys/fs/selinux/context". This is temporarily needed - until the necessary fix (included in Portage but not stable yet) is - available. -

- - - - -Installing a SELinux Kernel - - -

-Although the default Linux kernels offer SELinux support, we recommend the use -of the sys-kernel/hardened-sources package. -

- -

-(Only if you have not installed it previously of course)
-~# emerge hardened-sources
-

- -

-Next, reconfigure the kernel with the appropriate security settings. This -includes, but is not limited to -

- -

Support for extended attributes in the various file systems
Support system-call auditing
Support for SELinux

- -

-Below you can find a quick overview of the recommended settings. -

- -

-Under "General setup"
-[*] Prompt for development and/or incomplete code/drivers
-[*] Auditing support
-[*]   Enable system-call auditing support
-
-Under "File systems"
-(For each file system you use, make sure extended attribute support is enabled)
-<*> 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
-
-Under "Security options"
-[*] 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) --->
-

- -

-We recommend to use PaX as well. More information on PaX within Gentoo Hardened -can be found in the Hardened -Gentoo PaX Quickstart Guide. -

- -

-Build and install the new Linux kernel and its modules. -

- - - - -Update fstab - - -

-Next, edit /etc/fstab and add the following two lines: -

- -

-# The udev mount is due to bug #373381
-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
-

- - -In case of an MLS/MCS policy, you need to have the context with sensitivity -level, so ...:device_t:s0. - - - - - -Reboot - - -

-With the above changes made, reboot your system. Assert yourself that you are -now running a Linux kernel with SELinux enabled (the /selinux file -system should be mounted). Don't worry - SELinux is at this point not activated. -

- - - -

- -

-Configure SELinux - -Introduction - - -

-Next we will need to configure SELinux by installing the appropriate -utilities, label our file system and configure the policy. -

- - - - -Install Policies and Utilities - - -

-First, install the sys-apps/checkpolicy and -sys-apps/policycoreutils 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 -1 option. -

- -

-~# emerge -1 checkpolicy policycoreutils
-

- -

-Next, install the SELinux policy package -(sec-policy/selinux-base-policy). 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 -sys-apps/policycoreutils) we need to temporarily disable SELinux -support (as Portage wouldn't be able to label anything as it doesn't understand -it yet). -

- -

-~# FEATURES="-selinux" emerge selinux-base-policy
-

- -

-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 -selinux USE flag). Don't forget to use etc-update or -dispatch-conf afterwards as some changes to configuration files need to -be made. -

- -

-~# emerge -uDN world
-

- -

-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. -

- -

-~# emerge setools sepolgen checkpolicy
-

- -

-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. -

- -

-~# emerge --search selinux-
-[...]
-(Select the modules you want to install)
-~# emerge selinux-screen selinux-gnupg selinux-sudo selinux-ntp selinux-networkmanager ...
-

- - - - -Configure the SELinux Policy - - -

-Inside /etc/selinux/config you can configure how SELinux is -configured at boot time. -

- -

-# 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=permissive
-
-# 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
-

- -

-Within this configuration file, two variables can be set: -

- -

- SELINUX sets how SELinux should behave: -
- - enforcing will enable and enforce policies. This is where we want - to go for, but you should probably start with permissive. -
- - permissive 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 enforcing or not. -
- - disabled will completely disable the policies. As this will not - show any violations as well, it is not recommended. -
-
- SELINUXTYPE selects the SELinux policy type to load. - Gentoo Hardened recommends the use of strict for servers, and - targeted for desktops. The mcs type is supported, mls - is currently still considered experimental. -

- -

-The differentiation between strict and targeted is based upon the -unconfined 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". -

- -

-Next to targeted and strict, you can opt for mcs 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. -

- -

-Finally, you can also select mls to differentiate security domains on -a sensitivity level. However, MLS is currently still considered experimental -in Gentoo and as such not recommended. -

- -

-When you have made your choice between the SELinux policy types, save -this in your /etc/make.conf file as well. That way, Portage will -only install the policy modules for that SELinux type. -

- -

-~# nano /etc/make.conf
-POLICY_TYPES="strict"
-

- - - - -Reboot, and Label the File System - - - -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. - - -

-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. -

- -

-~# mkdir /mnt/gentoo
-~# mount -o bind / /mnt/gentoo
-
-(Substitute the "strict" in the next command with "targeted" if that is your SELINUXTYPE selection)
-~# setfiles -r /mnt/gentoo /etc/selinux/strict/contexts/files/file_contexts /mnt/gentoo/dev
-~# setfiles -r /mnt/gentoo /etc/selinux/strict/contexts/files/file_contexts /mnt/gentoo/lib64
-~# umount /mnt/gentoo
-

- -

-Next, if you have a swapfile rather than a swap partition, label it accordingly: -

- -

-~# semanage fcontext -a -t swapfile_t "/swapfile"
-~# restorecon /swapfile
-

- -

-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. -

- -

-~# rlpkg -a -r
-

- -

-If you ever have to install a SELinux policy module for a package after that -that particular package is installed, you need to run rlpkg for that -package to make sure that the security contexts for these files are set -correctly. For instance, if you have installed -sec-policy/selinux-screen after discovering that you have -screen on your system: -

- -

-(Make sure no screen sessions are running as their security contexts will not be adapted)
-~# rlpkg -t screen
-

- - - - -Reboot and Set SELinux Booleans - - -

-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 /dev/urandom device: -

- -

-~# setsebool -P global_ssp on
-

- - - - -Define the Administrator Accounts - - -

-If the SELINUXTYPE is set to strict, then we -need to map the account(s) you use to manage your system (those -that need access to Portage) to the staff_u SELinux user. If not, none -of your accounts will be able to succesfully manage the system (except for -root, but then you will need to login as root directly and not -through sudo or su.) By default, users are mapped to the -user_u SELinux user who doesn't have the appropriate rights (nor access -to the appropriate roles) to manage a system. Accounts that are mapped to -staff_u can, but might need to switch roles from staff_r to -sysadm_r before they are granted the appropriate privileges. -

- -

-Assuming that your account name is john: -

- -

-~# semanage login -a -s staff_u john
-~# restorecon -R -F /home/john
-

- -

-If you later log on as john and want to manage your system, you will -probably need to switch your role. You can use newrole for this: -

- -

-~$ id -Z
-staff_u:staff_r:staff_t
-~$ newrole -r sysadm_r
-Password: (Enter your password)
-~$ id -Z
-staff_u:sysadm_r:sysadm_t
-

- -

-If you however use a targeted policy, then the user you work with will be -of type unconfined_t and will already have the necessary privileges to -perform system administrative tasks. -

- -

-With that done, enjoy - your first steps into the SELinux world are now made. -

- - - -

- 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 @@ - - - - - - - - - -4 -2012-04-29 - -

-SELinux Policy Language - -Introduction - - -

-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. -

- -

-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. -

- - - - -Building a SELinux Module - - -

-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. -

- -

-Let's start with a skeleton for a policy module we'll call testmod. 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. -

- -

-policy_module(testmod, 1.0.0)
-

- -

-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). -

- -

-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 };
-

- -

-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 -testmod.te. -

- -

-To build the policy and convert it into the binary module that we can load into -the SELinux policy store, we can use the Makefile available in -/usr/share/selinux/strict/include (substitute strict with the -SELinux policy type you are using). -

- -

-$ make -f /usr/share/selinux/struct/include/Makefile testmod.pp
-

- -

-The filename (testmod.pp) is the destination binary SELinux module -name. The Makefile will automatically look for the -testmod.te file you have in the working directory. -

- -

-As a result, you should now have a file called testmod.pp. This -module file can now be loaded in the SELinux policy store as follows: -

- -

-# semodule -i /path/to/testmod.pp
-

- -

-Congratulations! You have now build your first SELinux policy module. If you -want to disable it, remove it through semodule -r testmod. -

- -

-This method of building a policy (using the Makefile and -semodule) 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. -

- - - - -Getting the SELinux Policy Interfaces - - -

-To streamline policy development, the SELinux policy based on the reference -policy uses interfaces to access privileges within a module. If you have built -selinux-base-policy with USE="doc" then this information is -available at -/usr/share/doc/selinux-base-policy-<version>/html. It is -recommended to have this information at hand, since most policy -development/updates will be done through the interfaces offered by the policy. -

- -

-If you are just interested, you can also find these interface definitions online. Mind you though, -the online resource is only the reference policy and might differ a bit from the -policy available within Gentoo. -

- - - - -Using Policy Interfaces - - -

-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: -

- -

-policy_module(testmod, 1.0.0)
-
-require {
-  type user_t;
-  role user_r;
-}
-
-portage_run(user_t, user_r)
-

- -

-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 ;-) -

- - - -

- -

-Full SELinux Policy Modules - -Checking Out an Isolated Module - - -

-With the above in mind, we can now go one step further and investigate a full -policy module, with both the type enforcement rules (.te file), -file contexts (.fc) and interfaces (.if). -

- -

-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. -

- -

-In this section, we will not divulge in how to write one. We have an excellent -Gentoo Hardened SELinux -Development resource that guides you in that. However, we will look into -such a full module to explain the other aspects of policy development. -

- - - - -Type Enforcement File - - -

-The .te file we wrote earlier is a type enforcement file. -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). -

- -

-The example below is a snippet from a module for the skype application. -

- -

-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)
-

- -

-In the above example, three new types are declared: skype_t (which will -be used for the application), skype_exec_t (which is the label given to -the application binary) and skype_home_t (which will be used for the -users' ~/.Skype location). Also, the skype_t domain is given -some privileges with respect to the skype_home_t label (manage -directories and files). -

- - - - -File Context File - - -

-In the .fc file (which stands for file context file) 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. -

- -

-The example below is a snippet from the skype modules' file context file. -

- -

-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)
-

- -

-The format of the file context file has the following syntax: -

- -

- The regular expression that matches the file(s) and directorie(s) affected - by that line -
- An optional identifier to differentiate the type of files (file, directory, - socket, symbolic link, ...) -
- A gen_context line that contains the context to assign to the file(s) - and directorie(s) -

- - - - -Interface File - - -

-In the .if file (for interface file) 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. -

- -

-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. -

- -

-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)
-')
-

- -

-Through this skype_role, we can then allow users to call skype, as can be -found in the unprivuser.te file (which defines the user_t domain): -

- -

-optional_policy(`
-	skype_role(user_r, user_t)
-')
-

- -

-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. -

- - - - - - - - - - - - _template - virt_domain_template(prefix) - - 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. - - - - - - - - - - - - - miscfiles_cert_type(resource) - - 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. - - - - - - - - - - - - _<access>_<resource> - mta_getattr_spool(domain) - - 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). - - - - _exec - dmesg_exec(domain) - - 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. - - - - _domtrans - dmesg_domtrans(domain) - - 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. - - - - _run - netutils_run(domain, role) - - 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). - - - - _role - xserver_role(role, domain) - - 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). - - - - _admin - aide_admin(domain) - - 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. - - -

Templates
Suffix	Example	Description
Transformations
Suffix	Example	Description
Access interfaces
Suffix	Example	Description

- - - -

- -

-Using audit2allow - -Introduction - - -

-When reading online resources on SELinux, you will notice that there are many -references to a tool called audit2allow. 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 -R -option) is not usable for the Makefile we used earlier to build -modules. -

- -

-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. -

- - - - -Using audit2allow - - -

-Using audit2allow is pretty straightforward. You send it the denials you -want to fix and store the result in a .te file. You then convert it -into an intermediary format which can then be translated into a .pp -file for final loading by semodule. -

- -

-For instance, to catch all denials and transform them into allowed statements -from firefox-related denials: -

- -

-# grep firefox /var/log/avc.log | audit2allow -m firefoxmod > firefoxmod.te
-# checkmodule -m -o firefoxmod.mod firefoxmod.te
-# semodule_package -o firefoxmod.pp -m firefoxmod.mod
-# semodule -i firefoxmod.pp
-

- -

-Keep the module name (given through the -m option) simple: only use -characters ([a-z]) and numbers ([0-9]), and start the module name -with a character. -

- - - -

- - 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 @@ - - - - - - - - - -2 -2012-04-29 - -

-SELinux States - -Introduction - - -

-When SELinux is available, it will generally be in one of three states on your -system: disabled, permissive or enforcing. -

- - - - -Disabled - - -

-When getenforce 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. -

- -

-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). -

- -

-The best way to go forward in such case is to boot in permissive mode and then -relabel the entire file system: -

- -

-# rlpkg -a -r
-

- - - - -Permissive - - -

-When SELinux is enabled in permissive mode (getenforce 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 not be prohibited. -

- -

-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 that are not SELinux aware 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. -

- -

-There is one caveat though: if the application is SELinux-aware (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. -

- -

-To find out if an application is SELinux aware, simply check if it is linked -against libselinux (with ldd or scanelf - part of -app-misc/pax-utils): -

- -

-# scanelf -n /bin/ls
- TYPE     NEEDED FILE
-ET_DYN   libselinux.so.1,librt.so.1,libc.so.6   /bin/ls
-

- - - - -Enforcing - - -

-If getenforce 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. -

- - - - -Switching States - - -

-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). -

- -

-Using the command setenforce: -

- -

-(Switching to permissive mode)
-# setenforce 0
-
-(Switching to enforcing mode)
-# setenforce 1
-

- -

-Using the kernel boot option enforcing: -

- -

-(The following GRUB kernel line would boot in permissive mode)
-kernel /kernel-2.6.39-hardened-r8 root=/dev/md3 rootflags=data=journal enforcing=0
-

- -

-Using the /etc/selinux/config SELINUX variable: -

- -

-# cat /etc/selinux/config
-# 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)
-SELINUXTYPE=strict
-

- -

-When you want to switch from permissive to enforcing, it is recommended to do so -in the order given above: -

- -

- First boot up in permissive mode, log on, verify that your context is - correct (id -Z) and then switch to enforcing (setenforce 1). - You can now test if your system is still working properly. -
- Next, boot with enforcing=1 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 -
- Finally, edit /etc/selinux/config to persist this change. -

- - - - -Domain-permissive Mode - - -

-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): -

- -

-# semanage permissive -a mplayer_t
-

- -

-With the -d option, you can remove the permissive mark again. -

- - - -

- -

-SELinux Policy Types - -Introduction - - -

-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): -targeted, strict, mcs (and mls). -

- -

-The type used on a system is declared in /etc/selinux/config: -

- -

-# cat /etc/selinux/config
-# 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)
-SELINUXTYPE=strict
-

- - - - -strict (without unconfined domains) - - -

-The strict 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. -

- - - - -targeted (using unconfined domains) - - -

-The targeted 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. -

- -

-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". -

- - - - -mcs (using multiple categories) - - -

-The introduction of mls and mcs offers the ability for -multi-tenancy: 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). -

- -

-A simple example is virtualization: a virtual guest which runs in the -qemu_t 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 mcs, 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). -

- - - - -mls (using multiple security levels) - - -

-The mls 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 public, private, confidential or strictly -confidential. 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. -

- - - - -Switching Types - - -

-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. -

- -

-First, you need to edit /etc/selinux/config so that it both -switches the policy type as well as put the mode in permissive. This is -necessary, since at your next reboot, many labels might (or will) be incorrect. -

- -

-Next, edit /etc/fstab and make sure that the domains you use there -are updated accordingly. For instance, the line for /tmp: -

- -

-# Example when switching from strict to mcs
-tmpfs  /tmp  tmpfs  defaults,noexec,nosuid,rootcontext=system_u:object_r:tmp_t:c0  0 0
-

- -

-When this is done, reboot your system. Log on as root, and relabel your entire -file system using rlpkg -a -r. 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". -

- - - -

- - 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 @@ - - - - - - - - - -2 -2012-04-10 - -

-Unable To Load SELinux Policy - -Problem Description - - -

-If you notice that SELinux is not functioning at all, a quick run of -sestatus should give you closure if SELinux is enabled and loaded or not. -If you get the following output, no SELinux policy is loaded: -

- -

-SELinux status:                disabled
-

- -

-If this is the case, read on in this section to find out how to troubleshoot and -resolve this. -

- - - - -No Policy Installed - - -

-One potential reason would be that there is no policy to load to begin with. -Take a look inside /usr/share/selinux/strict or -/usr/share/selinux/targeted (depending on your configuration) and -look for a file called base.pp. If no such file exists, you will -need to install the base policy. This policy is offered by the -sec-policy/selinux-base-policy package, but it is better to read up -on the chapter regarding Gentoo SELinux -Installation / Conversion as more important changes might be missing. -

- - - - -Policy Not Loaded - - -

-If the base.pp file exists in -/usr/share/selinux/strict (or targeted/), take a look -inside /etc/selinux/strict/policy. This location too should contain -a base.pp policy module (when a SELinux policy is loaded, it is -copied from the first location to the second). -

- -

-If no base.pp file exists, install and load the policy: -

- -

-~# semodule -n -B
-

- -

-This is a one-time operation - once installed and loaded, it will be reloaded -upon every reboot. -

- - - - -Init Can Not Load the SELinux Policy - - -

-During system boot, the init process is responsible for loading and -interacting with the SELinux policy in memory. If init does not support -SELinux, you will get no SELinux support in your environment. -

- -

-To verify if init supports SELinux, we need to check if it uses the -libselinux.so shared object: -

- -

-~# ldd /sbin/init
-        linux-vdso.so.1 =>  (0x00006ace30e84000)
-	( You should see something similar to the following line: )
-        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)
-

- -

-If this is not the case, make sure that emerge --info shows that the -selinux USE flag is in place, and reinstall sys-apps/sysvinit. If -the selinux USE flag is not in place, check your Gentoo profile and make sure it -points to a selinux/v2refpolicy/... profile. -

- - - - -Policy Store is Corrupt - - -

-If you encounter problems during boot-up or semodule 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. -

- -

-~# semodule -n -B
-libsemanage.semanage_load_module: Error while reading from module file
-/etc/selinux/targeted/modules/tmp/base.pp. (No such file or directory)
-
-~# setenforce 0
-~# mv /etc/selinux/targeted /etc/selinux/targeted.old
-~# FEATURES="-selinux" emerge -1av $(qlist -IC sec-policy)
-~# restorecon -R /etc/selinux
-

- -

-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 /etc/selinux are -restored, after which you should be able to continue. -

- - - -

- -

-Unable to Log On - -Problem Description - - -

-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 -sysadm_r in one way or the other. -

- -

-If you can not log in as a sysadm_r user, disable SELinux (boot with -enforcing=0) so that no SELinux enforcements are made. Changes that you -make in permissive mode are equally effective as in enforcing mode. -

- - - - -Incorrect Context - - -

-In the majority of cases will you find that a security context is incorrect. Run -sestatus -v and compare the Process contexts or File -contexts that you see in the output with the next table. -

- - - - - - - - - Init context - system_u:system_r:init_t - - First, verify that init itself is correclty labeled. Check the output of - the previously run sestatus -v command for the - /sbin/init file and make sure that it is set to - system_u:object_r:init_exec_t. If that is not the case, relabel - sys-apps/sysvinit using rlpkg sysvinit. Also make the - same checks as in the Unable To Load SELinux - Policy section. Reboot your system and retry. - - - - agetty context - system_u:system_r:getty_t - - Make sure that the /sbin/agetty binary is labeled - system_u:object_r:getty_exec_t. If not, relabel the - sys-apps/util-linux package using rlpkg util-linux. Then - restart all the agetty processes using pkill agetty (they will - automatically respawn). - - - - - - - - - /bin/login - system_u:object_r:login_exec_t - - The login binary is part of sys-apps/shadow. Run rlpkg - shadow to relabel the files of that package and retry logging in. - - - - /sbin/unix_chkpwd - system_u:object_r:chkpwd_exec_t - - This binary is part of the sys-libs/pam package and is used by - SSH when it is configured to use PAM for user authentication. Relabel the - package using rlpkg pam and retry logging in. - - - - /etc/passwd - system_u:object_r:etc_t - - The /etc/passwd and /etc/shadow must be labeled - correctly, otherwise PAM will not be able to authenticate any user. Relabel - the files through restorecon /etc/passwd /etc/shadow and retry - logging in. - - - - /etc/shadow - system_u:object_r:shadow_t - - - /bin/bash - system_u:object_r:shell_exec_t - - The users' shell (in this case, bash) must be labeled correctly so - the user can transition into the user domain when logging in. To do so, - relabel the app-shells/bash package using rlpkg bash. - Then, try logging in again. - - -

Process	Context	If wrong context...
File	Context	If wrong context...

- - - -

- -

-Unable to Emerge Anything (OSError: [Errno 22] Invalid argument) - -Problem Description - - -

-When trying to install software with Portage, you get a huge python stacktrace -and finally the error message OSError: [Errno 22] Invalid argument: -

- -

-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
-

- - - - -Wrong Context - - -

-The above error comes when you launch portage (through emerge) while you -are not in sysadm_t context. You can verify this with id -Z: -

- -

-~# id -Z
-system_u:system_r:local_login_t
-

- -

-As long as the context isn't sysadm_t, then Portage will break. This is -because Portage wants to switch its execution context from portage_t to -portage_sandbox_t but fails (it isn't in portage_t to begin with -because the user who launched Portage isn't in sysadm_t). -

- -

-Please check Unable to Log On above first. Also -make sure that you can dispatch-conf or etc-update after -installing SELinux so that /etc/pam.d/system-login is updated with -the right pam_selinux.so calls. -

- - - - -Forcing Installation - - -

-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 emerge command but with FEATURES="-selinux". This -will effectively disable Portage' SELinux integration, but allows you to -continue installing software. -

- -

-~# FEATURES="-selinux" emerge -u world
-

- -

-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 rlpkg -a --r. -

- - - -

- - 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 @@ - - - - - - - -SELinux -SELinux - - -SELinux is a system of mandatory access controls. SELinux can enforce -the security policy over all processes and objects in the system. - - - -

-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. -

- -

-Security-Enhanced -Linux (SELinux) is a Mandatory Access Control system using type -enforcement and role-based access control. It is integrated within Linux as a -Linux Security Module (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. -

- -

-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. -

- - - - -

-Our goal is to make SELinux (with Gentoo Hardened) available to more users. -As a result, we -

- -

- develop, improve and maintain the proper documentation and learning - material for end users to master SELinux -
- 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) -
- focus on the integration of SELinux and SELinux-awareness within the Gentoo - distribution, offering the necessary feedback on Portage and other utilities -
- 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 -

- - -SwifT -pebenito -blueness -prometheanfire - -Gentoo SELinux Handbook (concepts, installation, maintenance) -Gentoo SELinux FAQ -Gentoo Hardened SELinux Development Guide -Reporting SELinux (policy) bugs -Gentoo Hardened SELinux Development Policy -Gentoo Hardened Roadmap (includes SELinux development) -Gentoo Hardened Support Matrices (includes SELinux) - - -Contributors -

- - -

-The following people, although non-developer, are actively contributing to the project: -

- - -Chris RichardsgizmoPolicy development, support -

Contributor	Nickname	Role

- - -

- - - -I Want to Participate -

- -

-To participate in the SELinux project first join the mailing list at -gentoo-hardened@gentoo.org. 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 #gentoo-hardened on -irc.freenode.net 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. -

- -

-Policy Submissions - - -

-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: -

- -

- Make comments (in the policy and/or bug), so we can understand changes - from the Reference Policy example policy. -
- The policy should cover common installations. Please do not submit policies - for odd or nonstandard daemon configurations. -
- We need to know if the policy is dependent on another policy (for example - rpcd is dependent on portmap) other than base-policy. -

- -

-The policy should be submitted on bugzilla. -Please attach the .te and .fc files separately to the bug, not as a tarball. -The bug should be Cc'ed to selinux@gentoo.org and will be properly -reassigned by the team. -

- - -

- - - 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 @@ - - - - - - -Gentoo SELinux Handbook - - - Chris PeBenito - - - Sven Vermeulen - - - Chris Richards - - - -This is the Gentoo SELinux Handbook. - - - - - - -4 -2011-09-18 - - -Introduction to Gentoo/Hardened SELinux - -In this part we cover what SELinux is and how it is positioned within the -Gentoo/Hardened project. - - - -Enhancing Linux Security - -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. - - - - - -SELinux Concepts - -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. - - - - - -SELinux Resources - -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. - - - - - - - - -Using Gentoo/Hardened SELinux - -With the theoretic stuff behind us, let us start by installing Gentoo/Hardened -with a SELinux kernel as well as the SELinux tools. - - - -Gentoo SELinux Installation / Conversion - -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. - - - - - -Configuring SELinux For Your Needs - -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. - - - - - -SELinux Commands - -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. - - - - - -Permissive, Unconfined, Disabled or What Not... - -Your system can be in many SELinux states. In this chapter, we help you switch -between the various states / policies. - - - - - -Modifying the Gentoo Hardened SELinux Policy - -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. - - - - - -Troubleshooting SELinux - -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. - - - - - - - - -- cgit v1.2.3-65-gdbad