User:SwifT/selinux-tutorials/1

Overview

 * SELinux/Tutorials/The_security_context_of_a_process
 * a process is assigned a security context which, just like with the user under which the process runs, helps Linux in identifying what the application should and shouldn't be allowed to do, and
 * that a security context cannot change at the discretion of the process, but is instead governed by the SELinux policy itself
 * SELinux/Tutorials/How_SELinux_controls_file_and_directory_accesses
 * SELinux uses contexts for processes (domains) and contexts for files (types) as part of its internal language for allowing access
 * SELinux uses the allow : { }; syntax for this access
 * SELinux stores the security context (or SELinux context) of a file or directory as an extended attribute of this file
 * SELinux/Tutorials/Where_to_find_SELinux_permission_denial_details
 * denials are logged in the avc.log (no audit daemon running) or audit.log (audit daemon running) log files
 * denials might be obscured through dontaudit statements, which you can disable using semodule -DB and re-enable through semodule -B
 * the denial logging gives you great detail about who (process information, including security context) is trying to do what (permission) against something (target information, including security context)
 * SELinux/Tutorials/Controlling_file_contexts_yourself
 * the context of a file is one of the most important parts of a SELinux secured system,
 * that wrong contexts are the most common source of SELinux-related denials and permission problems,
 * that contexts are defined by mapping types with regular expressions through semanage fcontext, and
 * that contexts are then best applied through restorecon
 * SELinux/Tutorials/How_does_a_process_get_into_a_certain_context
 * SELinux by default inherits contexts, be it from processes (on fork) or parent files/directories
 * Contexts of processes can change on execute of a command from that process' context, but only under the conditions that
 * the target file context is executable for the source domain
 * the target file context is marked as an entrypoint for the target domain
 * the source domain is allowed to transition to the target domain
 * SELinux/Tutorials/Using_SELinux_booleans
 * SELinux supports booleans to dynamically update the run-time policy
 * the values of these booleans can be persisted across reboots
 * you can use sesearch to display the consequences of a boolean or to see if a boolean is available to allow certain statements
 * SELinux/Tutorials/Working_with_customizable_types
 * customizable types exist for files and resources that have no fixed location on a file system
 * the list of current customizable types can be found in
 * the context of files with a customizable type context can be reset if you use the force (-F) option during relabel operations
 * SELinux/Tutorials/Permissive_versus_enforcing
 * SELinux has two "modes" of operation: permissive and enforcing
 * in permissive mode SELinux does not enforce its policy, but only logs what it would have blocked (or granted)
 * applications that are SELinux-aware might still behave differently with permissive mode than when SELinux is completely disabled
 * specific types can be marked as permissive while the rest of the system is in enforcing mode
 * completely disabling SELinux has consequences on the file contexts so an entire system relabeling is needed afterwards
 * SELinux/Tutorials/What_is_this_unconfined_thingie_and_tell_me_about_attributes
 * unconfined domains run virtually without SELinux protection
 * unconfined domains are meant to have users run with little SELinux interference, whereas the network-facing daemons still run in confined, SELinux-protected domains
 * Gentoo supports multiple SELinux policy stores (which are the subdirectories in /etc/selinux)
 * SELinux has support for type attributes, which can group multiple different types and assign privileges to the entire group of types
 * SELinux/Tutorials/How_is_the_policy_provided_and_loaded
 * SELinux uses a modular design for its policies, similar as how the Linux kernel uses modules
 * a policy store is used to keep track of loaded policy modules and settings, and is governed through the SELINUXTYPE setting in
 * the semodule tool is used to load, unload, ... SELinux policies
 * SELinux/Tutorials/Defining_SELinux_users
 * SELinux users define what roles a user is allowed to go to
 * Linux accounts are mapped to SELinux users (but they are not the same) in a many-to-few relationship (usually)
 * the semanage login and semanage user set of commands are used to manipulate these settings
 * SELinux user information rarely changes in a session (mostly only when services are launched where they become system_u)
 * SELinux/Tutorials/Linux_services_and_the_system_u_SELinux_user
 * calling linux service scripts (init scripts) causes a change in SELinux user, role and domain, partially due to policy and partially due to the run_init command
 * some service scripts are not labeled the regular initrc_exec_t and require a different approach for calling them, and might result in the process to remain running under the users' SELinux user (but that's okay)
 * it is the SELinux policy that governs changes in roles and users