2 - Raspberry PI Community Projects

1 3
Those interfaces define the myapp_t type as a process domain that should be used by
any executable labeled with myapp_exec_t. Implicitly, this adds an exec_type attribute
on those objects, which in turn allows other modules to grant rights to execute those
programs: for instance, the userdomain module allows processes with domains user_t,
staff_t, and sysadm_t to execute them. The domains of other confined applications will
not have the rights to execute them, unless the rules grant them similar rights (this is the
case, for example, of dpkg with its dpkg_t domain).
1 4
logging_log_file is an interface provided by the reference policy. It indicates that files
labeled with the given type are log files which ought to benefit from the associated rules
(for example granting rights to logrotate so that it can manipulate them).
1 5
The allow directive is the base directive used to authorize an operation. The first parameter
is the process domain which is allowed to execute the operation. The second one
defines the object that a process of the former domain can manipulate. This parameter
is of the form “type:class“ where type is its SELinux type and class describes the nature
of the object (file, directory, socket, fifo, etc.). Finally, the last parameter describes the
permissions (the allowed operations).
Permissions are defined as the set of allowed operations and follow this template: { ope
ration1 operation2 }. However, you can also use macros representing the most useful
permissions. The /usr/share/selinux/default/include/support/obj_perm_sets.
spt lists them.
The following web page provides a relatively exhaustive list of object classes, and permissions
that can be granted.
➨ http://www.selinuxproject.org/page/ObjectClassesPerms
Now you just have to find the minimal set of rules required to ensure that the target application
or service works properly. To achieve this, you should have a good knowledge of how the
application works and of what kind of data it manages and/or generates.
However, an empirical approach is possible. Once the relevant objects are correctly labeled, you
can use the application in permissive mode: the operations that would be forbidden are logged
but still succeed. By analyzing the logs, you can now identify the operations to allow. Here is
an example of such a log entry:
avc: denied { read write } for pid=1876 comm="syslogd" name="xconsole" dev
➥ =tmpfs ino=5510 scontext=system_u:system_r:syslogd_t:s0 tcontext=
➥ system_u:object_r:device_t:s0 tclass=fifo_file
To better understand this message, let us study it piece by piece.
By observing this log entry, it is possible to build a rule that would allow this operation. For
example: allow syslogd_t device_t:fifo_file { read write }. This process can be automated,
and it's exactly what the audit2allow command (of the policycoreutils package) offers. This approach
is only useful if the various objects are already correctly labeled according to what must
398 The Debian Administrator's Handbook