selinux

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
selinux [2019/03/15 09:33] – [Boot parameters described] daniselinux [2024/11/30 11:28] (current) – [Creation of selinux module] admin
Line 1: Line 1:
 ====== SELinux ====== ====== SELinux ======
 +This document applies to Fedora 29. But, all should work on CentOS/REL 7.
 ===== General ===== ===== General =====
 +Before you can work with all the selinux tools, you must install the following packages first:
  
 +<code bash>
 +dnf -y install python3-policycoreutils policycoreutils-python-utils policycoreutils setroubleshoot-server setools-console libselinux-utils coreutils
 +</code>
 ==== File contexts ==== ==== File contexts ====
  
Line 378: Line 382:
   * **autorelabel=1** \\ This parameter will force the system to relabel. It does the same thing as “touch /.autorelabe; reboot”. Sometimes, if the machines labeling is really bad, you will need to boot in permissive mode in order for the autorelabel to succeed. An example of this is switching from strict to targeted policy. In strict policy shared libraries are labeled as shlib_t while ordinary files in ''%%/lib%%'' directories are labeled lib_t. strict policy only allows confined apps to execute ''%%shlib_t%%''. In targeted policy shlib_t and lib_t are aliases. (Having these files labeled differently is of little security importance and leads to labeling problems in my opinion). So every file in ''%%/lib%%'' directories gets the label ''%%lib_t%%''. When you boot a machine that is labeled for targeted with strict policy the confined apps try to execute lib_t labeled shared libraries so and they are denied. ''%%/sbin/init%%'' tries this and blows up. So booting in permissive mode allows the system to relabel the shared libraries as ''%%shlib_t%%'' and then the next boot can be done in enforcing.   * **autorelabel=1** \\ This parameter will force the system to relabel. It does the same thing as “touch /.autorelabe; reboot”. Sometimes, if the machines labeling is really bad, you will need to boot in permissive mode in order for the autorelabel to succeed. An example of this is switching from strict to targeted policy. In strict policy shared libraries are labeled as shlib_t while ordinary files in ''%%/lib%%'' directories are labeled lib_t. strict policy only allows confined apps to execute ''%%shlib_t%%''. In targeted policy shlib_t and lib_t are aliases. (Having these files labeled differently is of little security importance and leads to labeling problems in my opinion). So every file in ''%%/lib%%'' directories gets the label ''%%lib_t%%''. When you boot a machine that is labeled for targeted with strict policy the confined apps try to execute lib_t labeled shared libraries so and they are denied. ''%%/sbin/init%%'' tries this and blows up. So booting in permissive mode allows the system to relabel the shared libraries as ''%%shlib_t%%'' and then the next boot can be done in enforcing.
  
-==== Creation of selinux module ====+===== Creation of selinux module ====
 +Sometimes not all rules apply to a application. Then, you need to create your own ''selinux'' module. In this example the ''rrdtool'' binary:
  
 +  - Get information from ''/var/log/audit/audti.log'':<code bash>
 +p=rrdtool; grep 'comm="'$p /var/log/audit/audit.log | audit2allow -l
  
 +module local_rrdtool 1.0;
  
 +require {
 + type httpd_t;
 + type nagios_var_lib_t;
 + class file map;
 +}
 +
 +#============= httpd_t ==============
 +# src="httpd_t" tgt="nagios_var_lib_t" class="file", perms="map"
 +# comm="rrdtool" exe="" path=""
 +#!!!! This avc can be allowed using the boolean 'domain_can_mmap_files'
 +allow httpd_t nagios_var_lib_t:file map;
 +</code>
 +  - Create now the module configuration file *.te:<code bash>
 +p=rrdtool; grep 'comm="'$p /var/log/audit/audit.log | audit2allow -l -v -m local_$p > local_$p.te
 +</code>The result is now ''local_$p.te'' file.
 +  - Check now the syntax of the config file:<code bash>
 +checkmodule -M -m -o local_$p.mod local_$p.te
 +</code>This creates the ''local_$p.mod'' file.
 +  - Create now the module for selinux:<code bash>
 +semodule_package -o local_$p.pp -m local_$p.mod
 +</code>This results in ''local_$p.pp'' selinux module
 +  - Activate the module and copy it to ''/usr/share/selinux/targeted'' directory:<code bash>
 +semodule -v -i local_$p.pp
 +Attempting to install module 'local_rrdtool.pp':
 +Ok: return value of 0.
 +Committing changes:
 +Ok: transaction number 21.
 +
 +cp local_$p.pp /usr/share/selinux/targeted/
 +</code>
 +
 +<WRAP center round important 60%>
 +It's a good idea to use a prefix for the module name (in my case: ''local_'')!
 +</WRAP>
 +
 +<WRAP center round tip 60%>
 +If you want to create a module for more than one binary (because they are part of an application), just use ''audit2allow -a'' to create the module configuration.
 +</WRAP>
 +
 +===== States of selinux =====
 +
 +  * State of ''selinux'':<code bash>
 +sestatus
 +SELinux status:                 enabled
 +SELinuxfs mount:                /sys/fs/selinux
 +SELinux root directory:         /etc/selinux
 +Loaded policy name:             targeted
 +Current mode:                   permissive
 +Mode from config file:          permissive
 +Policy MLS status:              enabled
 +Policy deny_unknown status:     allowed
 +Memory protection checking:     actual (secure)
 +Max kernel policy version:      31
 +</code>
 +  * List all loaded ''selinux'' modules (there are many, use grep!):<code bash>
 +semodule -l
 +</code>
  • selinux.1552638835.txt.gz
  • Last modified: 2019/03/15 09:33
  • by dani