SELinux Game Learn SELinux By Doing

Dissecting an SELinux Denial

Here is a SELinux denial example:

type=AVC msg=audit(1363289005.532:184): avc:  denied  { read } for
pid=29199 comm="Trace" name="online" dev="sysfs" ino=30
scontext=staff_u:staff_r:googletalk_plugin_t
tcontext=system_u:object_r:sysfs_t tclass=file

Once you get to know this denial structure, you can translate this into the following:

The Trace process with PID 29199 tried to read a file called online
on a file system hosted on the sysfs device. This file has inode
number 30, and has the security context system_u:object_r:sysfs_t
assigned to it. The Trace process itself is running with the
staff_u:staff_r:googletalk_plugin_t context (domain).

The following section gives a part by part explanation. We do want to tell you though that the logs can be a bit different based on what is denied - for instance, a file read access shows a few different parts than a socket connect denial. The majority of fields however will be present in all cases.

Log type

Log Part: type=AVC

Only in the audit.log file; it informs the user what kind of audit log type this is. So in our case, it is an AVC log entry.

Timestamp

Log Part: msg=audit(1363289005.532:184)

Timestamp in seconds since epoch, meaning the number of seconds since January 1st, 1970. You can convert this to a more human readable format using date -d @ followed by the number, like so:

user $date -d @1363292159.532

Thu Mar 14 21:15:59 CET 2013

Log type (again)

Log Part: avc:

Informs the user what kind of log entry this is. In this case, an AVC log entry.

State (if enforced)

Log Part: denied

What SELinux did, which can be either denied or granted. Note that, if SELinux is in permissive mode, then it will still log as denied even though it was allowed.

Permission

Log Part: { read }

The permission that was requested / executed. In this case, it is a read operation. Sometimes the permission contains a set (like { read write } but in most cases, it is a single permission request).

Process PID

Log Part: for pid=29199

The process identifier of the process that took the action (in this case, tried to read)

Process CMD

Log Part: comm="Trace"

The process command (without arguments, and limited to 15 characters), which helps users identify what the process was in case the process is already gone (a PID is only useful if the process is still running).

Target name

Log Part: name="online"

The name of the target (in this case, the file name). This field depends heavily on the target itself; it can also be path=, capability=, src= and more. But in those cases, its purposes should be clear from the rest of the log.

Device

Log Part: dev="sysfs"

Device on which the target resides (in case of a file or file system). In this case, the device is sysfs so we have the hint immediately that this is for something inside /sys. Other valid examples are dev=md-0, dev=sda1 or dev=tmpfs.

Inode Number

Log Part: ino=30

The inode number of the target file. In this case, since we know it is on the sysfs file system (and thus in /sys), we can look for this file using find:

user $find /sys -xdev -inum 30

/sys/devices/system/cpu/online

Source Context

Log Part: scontext=staff_u:staff_r:googletalk_plugin_t

The security context of the process (the domain).

Target Context

Log Part: tcontext=system_u:object_r:sysfs_t

The security context of the target resource (in this case the file).

Target Class

Log Part: tclass=file

The class of the target. We have seen file already, and dir shouldn’t surprise you either. SELinux supports a whole lot of classes.

Try it!

Explore these commands using the tutorial vagrant box. Start the environment using
vagrant up tutorial
vagrant ssh tutorial
If you don't have the command, visit the getting started guide

More Tutorials

After this one, the following tutorials are recommended:

Portions of this page's content are copied from this page for non-commercial, education purposes.