Why I seldom file bugs against SELinux policy

Jan Pazdziora

Sr. Principal Software Engineer
OpenShift Security, Red Hat
26th January 2018

CC BY-SA License

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

This text is also available as slides in PDF format.

SELinux policy in distribution

  • Distributions like Fedora, CentOS, or RHEL ship software in packages (rpm).
  • By default, selinux-policy and -targeted (or -mls) packages with SELinux policy also get installed.
    • Rules for labeling files when rpm installs them (file contexts):


      • rpm -ql package | xargs ls -dZ
      • restorecon(8)
    • Rules that permit or deny interactions of processes with files, directories, ports, and other components of the operating system.
      • sesearch(1)

AVC denials

  • When SELinux policy does not allow application to do something ...
    • things start to fail;
    • AVC (Access Vector Cache) denial is often logged.
  • Sometimes, nothing is visibly broken, things work.
    • Yet AVC denials are still logged.
      • Is that the better situation ... or worse?
  • Who decides if what application attempted to do was correct?
  • Maybe the SELinux policy is right?

Where to find AVC denials?

  • /var/log/audit/audit.log, search for type=AVC
  • journal via journalctl, search for AVC avc
  • setroubleshootd and sealert
  • in beaker jobs in /avc subtests

  • Let's look at some AVC denials.
  • The goal is not to point fingers but to sharpen instincts.

Application and policy mismatch

avc:  denied  { read } for  pid=3728 comm="abc.cgi"
    name="objects.cache" dev="dm-0" ino=2364515
    tcontext=system_u:object_r:xyz_spool_t:s0 tclass=file permissive=0
avc:  denied  { open } for  pid=4311 comm="def.cgi"
    path="/var/spool/xyz/objects.cache" dev="dm-0" ino=2364515
    tcontext=system_u:object_r:xyz_spool_t:s0 tclass=file permissive=0
  • Someone needs to decide if their CGI scripts should be allowed to work with the spool directory directly.
  • To check if these are allowed on the current distribution:
    $ sesearch --allow -s xyz_script_t -t xyz_spool_t -c file

Application and policy mismatch

avc:  denied  { execute_no_trans } for  pid=9992 comm="xyzd"
    path="/usr/libexec/xyz/xyz-action" dev="dm-0" ino=5833743
    tcontext=system_u:object_r:xyz_exec_t:s0 tclass=file permissive=0
  • Someone needs to decide if their daemon should be allowed to call its utility directly.
avc:  denied  { execute } for  pid=19919 comm="xyz"
    name="prog" dev="md1" ino=57787811
    tcontext=system_u:object_r:prog_exec_t:s0 tclass=file permissive=0
  • New feature to process output of external program instead of just files.
  • Someone has to drive reflecting the new feature in the SELinux policy.
  • Possibly via SELinux boolean.

Application and policy mismatch

avc:  denied  { create } for  pid=1913 comm="xyz-actiond"
    tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0
  • If the utility should be creating config files in /etc, that needs to be reflected in the SELinux policy.
avc:  denied  { create } for  pid=24914 comm="xyz" name="ABC"
    tcontext=system_u:object_r:tmp_t:s0 tclass=file
  • Different application, creating cache under /var/tmp.
  • In the end, xyz was changed to use /var/lib/xyz/cache for its data.

Aligning application and policy

  • Very often, the name of the game is not to fix SELinux policy.
    • Often, the policy is not broken, to be fixed.
  • The task is to match the security policy with the service or application deployment expectations.
    • Yes, often yet another allow (or appropriate macro) gets added to the policy to allow the interaction.
    • But sometimes, AVC denials can point to suboptimal application setup.

Homework assignment

  • Pick software dear to your heart.
  • Figure out what SELinux types it uses for its files on disk ...
    • ... and for processes that it starts.
  • Check what operations are allowed for those processes.
  • Focus on weird things like
    allow xyz_t xyz_log_t:file { ... unlink write };
  • Get curious.
    • Why should an attacker be able to overwrite or remove the logs?

Unnecessary functionality

avc:  denied  { write } for  pid=977 comm="xyzd"
    name="root" dev="dm-0" ino=13
    tcontext=system_u:object_r:admin_home_t:s0 tclass=dir permissive=0
  • The gvfs creates ~/.cache at startup if XDG_RUNTIME_DIR is not set.
  • But xyz does not need gvfs at all, in the daemon.
  • Patched with

Unfortunate config defaults

avc:  denied  { create } for  pid=13354 comm="xyz" name="xyz"
    tcontext=system_u:object_r:xyz_log_t:s0 tclass=sock_file permissive=0
  • Upstream's configuration sets its socket location under /var/log/xyz.
  • Changed to configure it under /var/spool/xyz.
  • Following the general purpose of directories brings order and makes the setup more secure.

Executable memory

avc:  denied  { execmem } for  pid=805 comm="xyzd"
    tcontext=system_u:system_r:xyz_t:s0 tclass=process permissive=0
  • Patched with
    +LINKFLAGS="%{?__global_ldflags} -Wl,-z,noexecstack"

How much should the application do?

avc:  denied  { module_load } for  pid=12682 comm="modprobe"
    tcontext=system_u:system_r:xyz_t:s0 tclass=system permissive=0
  • The daemon calls modprobe directly.
    • If compromised, different module name can be passed to it.
  • Perhaps xyz_t should not be allowed to load kernel modules at all.
    • A single-purpose helper program with domain transition just to load specific module might be safer approach.
    • Or the module can be loaded before the daemon gets started (systemd service setup).

Application too eager to list directory

avc:  denied  { getattr } for  pid=28229 comm="xyz"
    path="/etc/group.lock" dev="dm-1" ino=135358895
    tcontext=unconfined_u:object_r:shadow_t:s0 tclass=file
  • AVC denial was logged while no requests were being processed by xyz.
  • Application used inotify on /etc.
  • It tried to stat any file that got changed, even if it only cared about resolv.conf.

Potential shell command injection

avc:  denied  { execute } for  pid=1938 comm="xyz"
    name="bash" dev="vda1" ino=5442 
    tcontext=system_u:object_r:shell_exec_t:s0 tclass=file permissive=0
  • I've grepped xyz sources and I do not see an explicit call to shell.
  • Maybe single-parameter system or exec call in scripting language is used where multi-parameter one would avoid shell invocation?

Filehandle leak

avc:  denied  { write } for  pid=11813 comm="abc"
    path="/tmp/xyz.lock" dev=dm-0 ino=1048770
    tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file
  • The xyz created lock file and let its filehandle leak to abc.
  • Patched with
    -LOG_LOCK = open(lockfile(), 'w')
    +LOG_LOCK = open(lockfile(), 'we')

Bug in config code

avc:  denied  { read } for  pid=26234 comm="xyz"
    path="/.xyz_data/7Ggn3Ecq/data" dev="dm-1" ino=1835032
    tcontext=system_u:object_r:root_t:s0 tclass=file permissive=0
  • The setup script was using uninitialized $HOME
  • Patched with
    +[ "$HOME" ] || HOME=`getent passwd $ID | cut -d: -f6`
    -[ "$HOME" ] || HOME=`getent passwd $ID | cut -d: -f6`

Bug in application C code

avc:  denied  { module_request } for  pid=25312 comm="xyz"
    kmod="net-pf-0" scontext=system_u:system_r:container_t:s0:c40,c45
    tcontext=system_u:system_r:kernel_t:s0 tclass=system permissive=0
  • Application code called socket on zeroed sockaddr.
  • Patched with
    +       if (!AF(addr))
    +               return NULL;
            s = socket(AF(addr), SOCK_DGRAM, 0);
  • Only caught in container because containerized domains are more restricted.

Who should get notified?

  • These days, when the admin did not play the defaults too much, things work with the default SELinux enforcing setup just fine.
  • Who should get notified when you see an AVC denial / SELinux bug?
  • Remember, the task is to ...
    • Match the security policy with the service or application deployment expectations.
  • Package maintainers know their applications and changes in them much better than SELinux policy maintainers.
  • When you see an AVC denial, you should notify ...
    • of all people ...

I don't file bugs against SELinux policy

  • When I see an AVC denial, I notify ...
    • Package maintainers of the software package.
    • By filing bugzilla against the appropriate component.

And so should you!


  • Note: It's OK when after reviewing and assessing it, the component maintainers reassign it to selinux-policy with an RFE to align the policy with the latest application behaviour.

Further work

  • The midterm homework: check SELinux policy of your favourite service.
  • Paul Moore's SELinux Loves Modularity talk on Sunday, January 28, 2018, at 11:00 am CET in C-D0207.
  • Provide feedback about this session: