User:SwifT/selinux-tutorials/3
The various resource classes SELinux supports
We have been looking at the file and file related denials and access controls in the previous tutorials. When you look at the denials in the avc.log or audit.log file, you will notice that there are many other denials for other resources. The complexity of the various permissions, together with the various classes, are why most people consider SELinux to be complex.
In effect, it is not SELinux that is complex, but the intimate knowledge that engineers / administrators need to have about how Linux works, how processes interact, what the various actions are that processes take, etc. SELinux only reflects this by supporting the fine-grained permissions that manage this behavior.
In this tutorial, we'll cover a few of the other classes and give you hints where you can find more information.
File classes
Linux file systems have several file types available. We have already covered a regular file, but there are other file classes available as well.
File class | Description |
---|---|
file | The regular file class |
dir | Regular directories |
lnk_file | Symbolic links |
sock_file | Sockets |
fifo_file | Named pipes (known as FIFOs) |
chr_file | Character device files |
blk_file | Block device files |
This granularity allows SELinux policy writers to grant certain privileges on regular files that are different for the privileges on socket files, even when both files have the same security context.
To find out what the possible privileges are that SELinux supports (the fine-grained permissions), you can check the /sys/fs/selinux/class or /selinux/class location. In that location, all classes that SELinux supports can be found, and in those locations you can find the supported permissions.
user $
ls /selinux/class/file/perms
append execmod getattr lock quotaon relabelto swapon create execute ioctl mounton read rename unlink entrypoint execute_no_trans link open relabelfrom setattr write
On the SELinux project site an overview of the classes and their permissions is given, with a high-level explanation what a permission is about.
The following permissions might be of specific interest to explain in more detail (for files).
File permission | Description |
---|---|
open | Is opening the file allowed by the context? This sounds like a trivial permission, but it also allows SELinux policies to support reading and writing to files without opening them - this is the case when the file is inherited (for instance, it was opened by the parent process and then the process forked, or because of redirection of input/output). |
execute_no_trans | The regular execute permission differs from execute_no_trans in the sense that the latter does not allow any transitions. So if a domain has execute_no_trans rights on an executable file, it is able to execute it but will not be allowed to transition to another domain. |
relabelfrom relabelto |
With the relabel permissions, the SELinux policy writer can control which domains are allowed to change the context of a file (or other resource). The relabelfrom means that the domain is allowed to change a context if the current context is the target ("relabel files with current context auditd_log_t"), whereas relabelto means that the domain is allowed to change the context towards a particular target ("relabel files towards the context auditd_log_t"). |
Consider the following denial:
Jun 22 11:55:53 localhost kernel: [ 1903.035548] type=1400 audit(1340358953.789:223): avc: denied { execute_no_trans } for pid=13986 comm="udisks-daemon" path="/usr/libexec/udisks-helper-ata-smart-collect" dev="sda5" ino=424115 scontext=system_u:system_r:system_dbusd_t tcontext=system_u:object_r:bin_t tclass=file
Here, you notice that a process (udisks-daemon) is trying to execute a (most likely) executable file (since it is labeled as bin_t) without a transition (meaning that it would keep running within the system_dbusd_t domain).
The difficulty now is to find out how to proceed on this, and this requires knowledge of both the process (what is the udisks-daemon trying to do) as well as the focus of the policy. In the above case, it is difficult to know that it is not the purpose of DBus-related domains to allow execution of regular binaries. Still, this is the case - most of the time, if a domain is not allowed to execute bin_t then this is on purpose. For DBus-related domains, the focus of the policies is to only allow execution of DBus-labeled commands, or use transitions towards another domain.
Socket classes
The following gives a list of socket related resource classes. Not all descriptions are filled in yet, but you can get a high-level introduction on these classes through the earlier mentioned SELinux project site. It is not important to know each and every class or what its purpose is. However, it is important to understand that there are different classes for different reasons, and that you can properly parse AVC denials knowing what the class means.
We won't mention them all, but those that are mentioned are classes you will find in AVC denials frequently.
Socket class | Description |
---|---|
tcp_socket | TCP port related activities; we find the common networking terms here as privileges. As tcp (and udp) sockets are a major part of system administration (especially for network services) we document the permissions for these in more detail further down this tutorial. |
udp_socket | Same but for UDP sockets |
For the TCP socket (and some of them for UDP as well), the following permissions are especially important to understand.
Permission | Description |
---|---|
connect | Initiate a connection |
connectto | Connect to a specified server socket |
bind | Bind a name to the socket. |
name_bind | Associate with port or file; for AF_INET sockets, controls relationship between a socket and it's port number; for AF_UNIX sockets, controls relationship between a socket and it's file |
listen | Listen for connections |
accept | Accept a connection |
Consider the following denial:
Aleph kernel: [81387.625721] type=1400 audit(1359545662.073:2222): avc: denied { node_bind } for pid=27109 comm="squid" scontext=staff_u:sysadm_r:sysadm_t tcontext=system_u:object_r:node_t tclass=tcp_socket
In this case, the squid process is trying to bind to a TCP socket on a specific address (IPv4 or IPv6) with label node_t. Now, the node_t label is used for generic addresses, and most SELinux-enabled systems thus only use the node_t label anyway. So the target context in the above denial isn't wrong - but the source context is. As the process is squid, it doesn't make sense that it runs in the sysadm_t user domain.
Other classes
There are other classes as well which are not really part of a more common set. We won't list them all here, but some of them you'll see often and thus deserve special mention.
Class | Description |
---|---|
process | The process class is for inter-process activities; we already know about the transition permission, but there is also execmem (allow execution of writeable memory), various signal-related permissions (like sigkill, sigstop, sigchld, ...) and more |
capability capability2 |
Linux capabilities (which is another powerful method of managing access on a Linux system) can also be governed through SELinux. Each of the capabilities is referred in a permission, such as chown (can change owner), dac_read_search (a root-running process can read/search non-root owned files or directories), setuid (can change effective uid), etc. |
security | SELinux security activities, such as checking a file context (check_context), loading SELinux policy (load_policy), managing SELinux booleans (setbool), ... |
What you need to remember
From this tutorial, you should remember that
- SELinux uses very fine grained permissions with several target classes
- interpreting AVC denials requires intimate knowledge of how a Linux system (or process) works