|
[ << ] [ < ] [ Home ] [ > ] [ >> ] 2. Configuring SELinux For Your NeedsContent: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. Run semanage login -l to show the current mappings between Linux logins and SELinux users.
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.
To map a user to a specific SELinux user, use semanage login -a:
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:
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:
Let's verify how the SELinux users are currently configured:
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":
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:
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. 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... 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.
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. Below you'll find a typical AVC denial message.
Let's analyze each part of this message one by one.
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).
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.
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
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:
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:
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:
In most cases though, denials need to be acted upon. Actions that might need to happen are:
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). 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:
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:
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:
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:
If you have the permission, then you can use chcon to change the context of a file:
If you do not hold the right privileges, you will get a descriptive error message:
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:
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.
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:
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:
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:
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:
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:
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:
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. 2.d. SELinux Policy and Booleans 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:
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.
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:
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:
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:
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:
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:
Up until now, your system has been running in permissive mode. You will need to enable enforcing before you are properly protected by SELinux. We will discuss how to switch to enforcing mode in Permissive, Unconfined, Disabled or What Not... but before that, you will need to consider a few things... If your system uses an initramfs to boot up, you will not be able to boot straight into enforcing mode (due to bug #397597). To work around this issue, you can create the following init script which will switch from a permissive mode into forcing mode reasonably fast within the boot process (and before the network is started):
Add the init script to the boot runlevel, and edit your boot loader configuration to always boot with enforcing=0 set. The init script will update the file contexts in /dev and then, if your system is configured to run in enforcing mode, switch to enforcing mode. If you need to temporarily stay in permissive mode, you can add nosetenforce as boot parameter (after enforcing=0) which will skip the setenforce step). Users of a graphical environment If you boot into a graphical environment (using GDM, KDM or another graphical login manager) you will need to update the PAM configuration file(s) of the managers with the following:
This will ensure that the security context in which you are logged on is set correctly. We will update the packages that place those PAM files accordingly, but it might take some time. [ << ] [ < ] [ Home ] [ > ] [ >> ] The contents of this document, unless otherwise expressly stated, are licensed under the CC-BY-SA-2.5 license. The Gentoo Name and Logo Usage Guidelines apply. |
|