SELinux

SELinux is another layer of security complexity that sits below regular GNU user/group/other permissions.

Here are some links:

• https://wiki.centos.org/HowTos/SELinux
• https://selinuxproject.org/

Terminology

Context

A context is an n-tuple of:

• user
• role
• type
• range (optional)

Usually denoted as:

user:role:type
user:role:type:range

By convention: users end with _u, roles end with _r, and types end with _t.

e.g.:

$ ls -Z ~/.bashrc
-rw-------. matty default unconfined_u:object_r:user_home_t:s0 /home/matty/.bashrc
$ ps -Z
LABEL                             PID TTY          TIME CMD
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 53168 pts/0 00:00:00 bash
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 54566 pts/0 00:00:00 ps

Range

Written as: sensitivity:categories

Sensitivity:

• single level: s0
• range of levels: s0-s0

Categories:

• specified individually: c0,c5,c10
• treated as ordered set: c0.c10 (= c0,c1,c2,...,c9,c10)

I don't know what any of this actually means.

Class

Object classes (file, dir, lnk_file, etc.) and the set of permissions that can be configured on each.

See: https://selinuxproject.org/page/ObjectClassesPerms

Policy

/etc/selinux/<policy_name> – by default we seem to always use a policy called "targeted"

A policy has a bunch of 'modules' – on my RHEL7 server these can be found in /etc/selinux/targeted/active/modules/ (inside sub-directories for each priority?)

Policies are made of rules, e.g.:

allow user_t user_home_t:file { create read write unlink };

According to this rule the user_t type is allowed to create, read, write, and unlink files that have the user_home_t type.

The process of creating or updating these is interesting.

Example Policy Creation

If a particular action is failing, for example your Apache httpd process is having trouble writing files under /var/www/ you can auto-generate a policy to fix it, using Magic™:

$ grep httpd_t /var/log/audit/audit.log | audit2allow -M foobar
$ cat foobar.te

audit2allow generates a .te file (the source) and a .pp file (the compiled policy.) In this case the .te file includes this line:

#!!!! This avc can be allowed using the boolean 'httpd_unified'

..which tells me I could use the semanage boolean command (below) to fix it without generating a new policy. If I decided to edit the .te file by hand I could recompile it:

$ checkmodule -M -m -o foobar.mod foobar.te
$ semodule_package -o foobar.pp -m foobar.mod

A compiled .pp file can be loaded into your SELinux system:

$ semodule -i foobar.pp

Remember: "foobar" is a Bad Name™ for a module. Do not use it.

Commands

• chcon – change a file's context
• restorecon – resets it
• runcon – executes a command with a specified context
• semanage
  • semanage login -l – map of GNU user ↔ SELinux user
  • semanage user -l – list of SELinux users and their roles
  • semanage fcontext -l – list of managed file contexts (see also: restorecon)
  • semanage boolean -l – list of individual functions that can be functioned
  • semanage export – shows the semanage commands needed to get back to your current configuration
• seinfo – query components of a policy
  • seinfo -u – list of users
  • seinfo -r – list of roles
  • seinfo -t – list of types
  • seinfo -t -x – list of types with their attributes