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