SELinux/Unsound or dangerous SELinux policy practices

This document describes common issues of custom policy modules and suggests possible cause of the issue in cases where a predominant cause is known. It should serve as a guide for troubleshooting issues discovered by the DSP testsuite, as well as an educational tool for new policy writers and maintainers.

Custom policy module fundamentals

Each policy module should be self contained -- should not need any other modules (except for base policy that contains mandatory definitions such as object classes, or permissions) to function properly. This is achieved using the following principles:

• all domains that are influenced (granted access to some resource) by given module are defined in it
• Plain allow rules only grant access to types defined in the same module
• Each module defines interfaces to all resources that should be accessible by other modules
• The module resources (e. g. types) can only be accessed from other modules using interfaces (i.e. Access to other resources is always granted using interfaces defined by the module that defined given resource)
• Similarly, attribute assignment is only done in its parent module (module that defined given attribute), or by parent module interfaces

Not adhering to these may lead to compatibility issues, but more importantly may cause unforeseen effects on the rest of the security policy.

Notes:

Never allow

The following issues can only be left unresolved with a documented exception from the selinux team.

policy management permissions:

• load_policy, setenforce, setsecparam, etc. are reserved for SELinux userspace tools

Access to sensitive data -- the following resource types should only be accessed by kernel and security related tools:

• Kernel
  • sys_module access / CAP_SYS_MODULE capability (loading/removing kernel modules)
  • modules_object_t, modules_conf_t, modules_dep_t, kmod_exec_t, kmod_exec_t, kmod_exec_t, kmod_tmp_t, boot_t, system_map_t
• Selinux (policy, userspace tools and configuration files)
  • (write/append) selinux_config_t, default_context_t, file_context_t, semanage_store_t, semanage_read_lock_t, semanage_trans_lock_t, load_policy_exec_t, setfiles_exec_t, checkpolicy_exec_t, newrole_exec_t, policy_src_t, restorecond_exec_t, run_init_exec_t, setsebool_exec_t, semanage_exec_t, selinux_var_lib_t
• Other restricted files
  • security_t, shadow_t, var_log_t(write), user_home_dir_t, user_home_t, ssh_home_t,

Warnings

The following part describes policy elements that usually indicate issues in component or policy module design and are generally not advisable to use. However, there are (rare) cases where they are needed to ensure proper functionality.

Permissions:

• Write and execute permissions to single file type
  • Possibly a bug in application -- this shouldn’t be needed
• Execheap / execmem / execstack / execmod - (mapping memory that is both writable and executable)
  • Only necessary for JIT compilers and similar
• Dyntransition (change the domain type on a process at any time, not just when executing an application)

Capabilities (See “man 7 capabilities” for description):

• Dac_override, dac_read_search (process running as root is attempting to circumvent DAC settings on target file or a directory)
  • usually a bug in application or unnecessary access attempt (in the latter case a dontaudit rule should be created -- SELinux will stop reporting the corresponding AVC)
• mmap_zero (mapping a low area of the address space)
  • Probably a bug in application
• CAP_SETUID (arbitrary manipulations of process UIDs)
• SYS_ADMIN /sys/ (reassociate thread with a namespace)
  • A powerful capability which may indicate a bug in the application
    • Don't choose CAP_SYS_ADMIN if you can possibly avoid it! A vast proportion of existing capability checks are associated with this capability (see the partial list above). It can plausibly be called "the new root", since on the one hand, it confers a wide range of powers, and on the other hand, its broad scope means that this is the capability that is required by many privileged programs. Don't make the problem worse. The only new features that should be associated with CAP_SYS_ADMIN are ones that closely match existing uses in that silo.
  • Examples where the capability is actually needed (may not be apparent):
    • systemd-bootchart needs to modify a sysctl tunable before accessing /proc/schedstats
    • ptp4l needs to execute bpf programs in an attached filter in setsockopt()
• SYS_PTRACE (trace arbitrary process -- including access to it’s memory)
• MAC_ADMIN (MAC configuration and state changes)
  • Domain is trying to set non-existing SELinux type to some object
• CAP_FOWNER (bypass permission checks for operations normally only allowed to owner of given resource)
• CAP_FSETID (don't clear set-user-ID and set-group-ID bits after file modification)

Assignment of sensitive/powerful attributes (too powerful interface may have been used):

• Attributes allowing excessive write access
  • container_runtime_domain, files_unconfined_type, unconfined_domain_type, login_pgm, container_domain, svirt_sandbox_domain
• Attributes allowing excessive access
  • container_runtime_domain, staff_usertype, user_usertype, sysadm_usertype, antivirus_domain, setfiles_domain, boinc_domain, unconfined_domain_type, user_mail_domain, virt_domain, openshift_domain, sudodomain, nova_domain, consolehelper_domain, xguest_usertype, tomcat_domain, guest_usertype, policy_manager_domain, container_domain, svirt_sandbox_domain, postfix_domain, telepathy_domain, pcp_domain, mailman_domain, munin_plugin_domain, systemd_domain, cups_domain, seunshare_domain, wine_domain, files_unconfined_type

Other

• Transition to unconfined domain (unconfined_t, unconfined_service_t)
  • Probably misconfigured domain transition

Resources

• DSP packaging guide
• DSP testsuite repository