SELinux adds another layer of permission checks on Linux systems. Every object in system is assigned a label (one label per object), called security context. The context is usually displayed in user_t:role_t:type_t format, but for the scope of this answer the relevant part is the last component of the representation, the type.

SELinux policy contains the rules for what operations are allowed between these contexts. SELinux operates on whitelist rules. Anything not explicily allowed by the policy is denied. The reference policy contains policy modules for many applications and it is usually the policy used by SELinux enabled distributions. This answer is primarly describing how to work with a policy based on the reference policy, which you are most likely using if you using the distribution provided policy.

For processes, the type in the context is called domain. Processes are assigned a context when the file is executed (execve syscall). If the policy doesn't contain rules describing a new security context, the new process inherits the context from the calling process. SELinux aware programs can also change their context runtime. The policy describes what executions and context transitions are allowed. You can view in what context your process is running in with ps Z $PID.

Security context for files are stored on file extended attributes. You can view the labels on files using ls -Z. File context for new file is inherited from the directory or set by the policy on creation. SELinux maintains a database for paths and default file contexts. This database can be queries using semanage tool.

When you run your application as your normal user, you probably do not notice SELinux in any way. Default configuration sets the users in unconfined context. Processes running in unconfined context have almost not restrictions in place.

On SELinux enabled systems regular DAC permissions are checked first, and if they permit access, SELinux policy is consulted. If SELinux policy denies access, a log entry is generated in audit log in /var/log/audit/audit.log or in dmesg if auditd isn't running on the system.

Typical issues

• Files might have incorrect/incompatible file contexts when they are placed in non-default location. Files moved with mv also keep their metadata including file security contexts.

• If you have multiple daemons using the same files, the default policy might not include rules to allow the interaction between the security contexts.

Files in non-default location: relabel the files

If the files are not used by another deamon (or other confined process) and the only change is the location where files are stored, the required changes to SELinux configuration are:

• Add a new rule to file context database
• Apply correct file contexts to existing files

The context used on the default location can be used as template to for the new location. Most policy modules include man page documentation (generated using sepolicy manpages) explaining possible file contexts.

To add a new entry to file context database:

semanage fcontext -a -t <type> "/path/here/(/.*)?" 

After new context entry is added to the database, the context from database can be applied on your files using restorecon <files>.

Testing a new file context without adding a new entry in database

Context can be changed manually with chcon tool. This is useful when you want to test the new file context without adding an entry to file context database.

New file context is specified in the arguments to chcon. When used with --reference= option, the security context from a reference file is copied to the target files.

chcon --reference=<path to default location> <target files> 

Note about different file systems & mount points

If the new location is its own mount point, the context can be set with a mount option. Context set with mount option isn't stored on disk, so it can also be used with file systems that do not support extended attributes.

mount <device> <mount point> -o context="<context>" 

Allowing processes running in different security contexts (domains) to use the same files

Option 1: Booleans

Reference policy includes tunable options (booleans) which enable/disable certain additional rules. Many of them allow inter-operation of different system daemons which usually do not use same files.

List of all possible tunable options and their descriptions can be listed using semanage boolean -l. audit2allow might also be able to directly tell which boolean needs to be enabled.

To enable/disable a boolean using semanage:

semanage boolean --on <boolean name> semanage boolean --off <boolean name> 

Booleans are the simplest way to modify the policy. However, all possible situations can not be addressed by toggling a boolean. Some booleans also allow very broad access, being overly permissive.

Option 2: Extend policy with a new module

If no boolean exists to allow the access, the policy needs to be modified by adding a custom module.

A simple module adding the required rules to allow access can be generated from log files using audit2allow by following steps:

1. Set the daemon's domain (security context) to permissive mode. In permissive mode the policy isn't enforced, but logs are generated on the access the policy would normally deny.

    semanage permissive -a <domain> 

2. Test your daemon in normal operation to generate log entries.

3. Create a new policy module and insert it.

    audit2allow -a -M <name> semodule -i <name>.pp' 

4. Re-enable enforcing mode

    semanage permissive -d <domain>