SELinux security context labels are mandatory access control attributes that define the permissions of processes and files. Each process inherits a label containing a user, role, type, and level. Understanding these labels is essential for diagnosing permission denied errors and configuring secure Linux environments.
The Structure of SELinux Contexts
Every object in an SELinux-enabled system, whether it is a file, directory, socket, or process, carries a security context. This context is a string composed of four distinct fields separated by colons. The format generally follows the pattern:user:role:type:level. For processes, the most critical component is the type field, which determines what resources the process can access.
The user field does not refer to the Unix user ID but rather to the SELinux user identity. This allows multiple Unix users to share the same SELinux user space, simplifying policy management. The role field defines what actions the user or process can take within the context of the type. While roles are often set to system_u for system services, they play a vital part in defining administrative boundaries.
The type field is the primary mechanism for controlling access. Policies define rules based on types, such as allowing httpd_t (the HTTP daemon type) to read content from httpd_sys_content_t. If a process tries to access a resource with a mismatched type, SELinux denies the operation unless an explicit rule exists. The level field indicates the sensitivity and classification of the data, supporting multi-level security models used in government and military applications. Most standard Linux distributions use simplified levels like s0, but understanding the hierarchy helps when dealing with complex security requirements.
Assigning Contexts to Processes
When a process starts, it inherits its security context from the parent process or the executable binary itself. The kernel reads the security context associated with the binary file on disk. If the file has no specific context, it falls back to the default type defined in the policy for that executable name. Administrators can explicitly set the context using thechcon command or by setting persistent labels with semanage fcontext.
For systemd services, the context is determined by the service unit file and the binary it executes. If a service fails to start due to permission issues, checking the process context is the first diagnostic step. You can view the current context of a running process by examining the /proc/[pid]/attr/current file. This provides real-time insight into what SELinux believes the process is allowed to do.
It is important to note that contexts are not static. When a process forks new threads or execs new binaries, the context may change based on the new executable's label. This dynamic assignment ensures that privilege escalation attempts are contained within the bounds of the original type. Understanding this inheritance chain is crucial for troubleshooting why a script or application behaves differently under SELinux than it does in permissive mode.
Understanding and Using SEBOOL Settings in Tech Support explains how boolean settings can temporarily alter these strict type-based rules without modifying the underlying policy.
Diagnostics and Troubleshooting
When SELinux blocks an action, it logs the event in the audit log. The commandausearch -m avc -ts recent retrieves recent Access Vector Cache denials. These logs contain detailed information about the source type, target type, and the specific permission that was denied. Analyzing these logs allows administrators to identify exactly which type transition or access rule is missing.
Another useful tool is ps -eZ, which lists all running processes along with their full security contexts. This output helps verify if a process has the expected type. If a custom application is failing, you might need to create a new type for it or adjust the existing policy. Tools like audit2allow can generate policy modules from denial logs, providing a starting point for creating custom rules. However, relying solely on auto-generated policies can weaken security, so manual review is recommended.
In cases where immediate testing is required, switching SELinux to permissive mode with setenforce 0 allows operations to proceed while still logging denials. This is helpful for debugging complex interactions without risking system availability. Remember that permissive mode does not enforce restrictions, only records them. Once the issue is resolved, switch back to enforcing mode with setenforce 1 to restore full protection.
Securing an Ubuntu Server for Development Purposes discusses broader server hardening strategies that complement SELinux configurations.
Managing Persistent Labels
Usingchcon changes the context immediately but does not survive a relabeling event or filesystem restore. For permanent changes, use semanage fcontext to add entries to the SELinux file context database. After adding the rule, apply it to the filesystem using restorecon. This two-step process ensures that the context persists across reboots and backups.
For example, to set a custom web directory to be readable by Apache, you would add a rule for the path and then run restorecon. This method integrates with the overall policy framework, ensuring consistency across the system. It is also possible to manage process contexts via systemd directives, though modifying file contexts is the more common approach for application-specific adjustments.
Proper management of contexts prevents the need to disable SELinux entirely. A well-configured system maintains high security while allowing legitimate applications to function correctly. Regular audits of contexts help identify misconfigurations before they lead to outages.
Frequently Asked Questions
How do I check the SELinux context of a specific file?
You can use the ls -Z command to display the security context of files and directories. This output shows the user, role, type, and level fields clearly. For a more detailed view including extended attributes, consider using getfattr.
What happens if I disable SELinux completely?
Disabling SELinux removes mandatory access controls, leaving your system vulnerable to exploits that rely on local privilege escalation. While it may resolve immediate compatibility issues, it significantly reduces your security posture against malicious actors.
Can I change the SELinux context of a running process?
No, you cannot directly change the context of an already running process. You must stop the process, update the context of its executable or configuration files, and then restart it. The new context will be applied upon launch based on the updated labels.
Why do my custom scripts fail under SELinux?
Custom scripts often lack appropriate type definitions in the default policy, causing them to run with a generic type that lacks necessary permissions. You may need to create a custom module or use a predefined domain like shell_exec_t to allow execution.
How does SELinux interact with Docker containers?
Docker containers run in isolated namespaces, and SELinux applies labels to container processes separately. By default, Docker uses the container_t type. Proper labeling ensures that containers cannot access host resources outside their designated scope.