User:SwifT/selinux-tutorials/1

From Gentoo Wiki
Jump to:navigation Jump to:search

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 <domain> <type>:<class> { <permissions> }; 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 /etc/selinux/*/contexts/customizable_types
    • 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 /etc/selinux/config
    • 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
  • SELinux/Tutorials/Putting_constraints_on_operations
    • constraints are an integral part of the SELinux policy
    • when something is denied even though there are (type enforcement) rules that allow it, chances are very high that a constraint is involved
    • constrains don't limit (blacklist) what is allowed, but filter (whitelist) what is
  • SELinux/Tutorials/SELinux_Multi-Level_Security
    • SELinux supports sensitivity levels (hierarchical) and categories (labels)
    • the SELinux policy dictates what is allowed based on the dominance between two contexts
    • distributions usually do not provide a starting set of sensitivities and categories
  • SELinux/Tutorials/SELinux_Multi-Category_Security
    • MCS is a 'smaller' version of MLS
    • users (or applications) are responsible for handling the sensitivity (within the limits of what is allowed by policy), SELinux does not automatically 'deduce' the right context
  • SELinux/Tutorials/Managing_network_port_labels
    • SELinux also labels udp/tcp ports as it is one of the many resources it governs
    • you can assign existing labels to other ports using semanage port
  • SELinux/Tutorials/Creating_your_own_policy_module_file
    • policies are written through the .te files, with optional .fc and .if files
    • policy modules are build based on the above files, resulting in a loadable .pp file
    • policy development prefers the use of the interfaces provided by other modules
Retrieved from "https://wiki.gentoo.org/index.php?title=User:SwifT/selinux-tutorials/1&oldid=15857"