As we have learned from the previous recipe in this chapter, SELinux is all about labels and policies. In this recipe, we will show you how to work with these labels, also known as security contexts.
To complete this recipe, you will require a working installation of the CentOS 7 operating system with root privileges. It is assumed that you are working through this chapter recipe by recipe, so by now you should have installed the SELinux tools from the previous recipe and generated all the SELinux man pages for the policies. As you may notice, some of the commands that we will show you in this recipe have already been applied in other recipes in this book. We will explain them here in detail. For using the netstat
program, install the package, net-tools
, with the YUM package manager.
As we have learned in a previous recipe, almost every component in a SELinux system is an object (files, directories, processes, users, and so on). We will begin this recipe by showing you how to print out the SELinux labels for all kinds of objects using the -Z
command-line flag, which a lot of basic Linux commands on a SELinux system support.
id -Z ls -Z ps -auxZ netstat -tulpenZ
httpd
labels only):semanage fcontext -l | grep httpd
touch /tmp/selinux-context-test.txt
user_tmp_t
):ls -Z /tmp/selinux-context-test.txt
user_tmp_t
type to a random samba_share_t
label name:semanage fcontext -a -t samba_share_t /tmp/selinux-context-test.txt restorecon -v /tmp/selinux-context-test.txt
ls -Z /tmp/selinux-context-test.txt
Here in this recipe, we have shown you how to display labels (security contexts) of various SELinux object types, how to show all available label names, and how to modify or set them on the example of the file object. Working on a SELinux enhanced system on a daily basis, most administrators would confirm that the most important objects we have to manage security contexts for are files, directories, and processes. Also, you need to remember that every SELinux object can have only one security context.
So, what did we learn from this experience?
As we have have seen, we can use the -Z
parameter on a lot of different standard Linux command-line tools to print out their SELinux security context. Here, we have shown you examples to display labels for users, files and directories, processes, and network connections, which we could query with the id
, ls
, ps
, and netstat
commands. In the output of these commands, we see that every security context label of every such object consists of three values: user (flagged by _u
), role (_r
), and type (_t
). The type field is used as the main mechanism to do all our access control decisions in the standard SELinux type (which is called targeted), so we often call the whole SELinux access control process type enforcement (TE).
The other values user and role in an object's label are only necessary for very advanced SELinux configurations not discussed here. In order to show all the available context types for use on our system, use the command-line seinfo -t
. These SELinux types are a very important concept that we need to understand. For file and directory objects, they are used to bundle together groups of objects related to each other, and that should be protected or treated the same so that we can define specific policy rules on them. For example, we can assign each file in the standard mail spool directory, /var/spool/mail
, of the type mail_spool_t
, and then create an access rule policy in which we will use this type to allow specific access. In the context of processes, type values are called domains. Here, types are used as a way to isolate and sandbox processes: any process that has a specified domain name can only communicate and interact with other processes in the same domain (with some exceptions, such as transitions not discussed here). This isolating of processes via domains greatly reduces security risks. When processes get compromised, they can only damage themselves and nothing else.
If you type in ps -auxZ
, you will also see that there are processes that run in a domain called unconfined_t
. Processes running with this label are not protected by SELinux policies, which means that, if an unconfined process is compromised, SELinux does not prevent an attacker from gaining access to other system resources and data. Here, security falls back to standard DAC rules, which will be your only and exclusive protection instead.
After we discussed how to display security contexts, next in the recipe we showed you how you can set and change them. In some older documentation as well as in some SELinux policy man
pages, you will encounter examples with a tool called chcon
, which is used to modify the security context of your objects. The usage of this tool is not the recommended approach any more, and you should always replace such command line examples with the newer semanage fcontext -a -t
command-line in combination with the restorecon
program. For semanage
, you provide the label type name with -t
, and then provide the filename you want to set it for. Then, with restorecon
, you provide the filename to which you want to apply the change made by semanage
earlier. This is needed because security context can be set on two levels. It can be set to the policy and on a filesystem level. The chcon
command sets the new context directly on the filesystem, while the policy context does not get altered. This can be a problem, for example, if you want to reset or change the security context of your filesystem later (this is called relabeling)—which means that all the security context will be applied from the policy to the filesystem, overwriting all your changes made with chcon
. So it is better to use semanage
, which will write to the policy, and then use restorecon
, which will synchronize the policy labels to the filesystem, keeping everything up-to-date. If you want to set labels for directories instead of single files, you can use regular expressions; to see some examples and further command-line options; type man semanage-fcontext
and browse to the EXAMPLES
section.