SElinux Targetted Policy Part 2

Booleans

Booleans, as we all know, are variables that can either be set as true or false. Booleans enhance the effect of SELinux policies by letting the system administrator fine tune a policy. A policy may protect a certain daemon or service by applying various access control rules. In real world scenarios, a system administrator would not like to implement all the access controls specified in the policy.

This is where Booleans help. Booleans create conditional access controls based on their value. As an example, the httpd (Apache Web Server) subject has the following Booleans in the targeted policy:

allow_httpd_mod_auth_pam
allow_httpd_bugzilla_script_anon_write
httpd_enable_ftp_server
allow_httpd_squid_script_anon_write
allow_httpd_anon_write
httpd_can_network_relay
httpd_disable_trans
httpd_tty_comm
httpd_unified
httpd_rotatelogs_disable_trans
httpd_builtin_scripting
httpd_enable_cgi
allow_httpd_nagios_script_anon_write
httpd_suexec_disable_trans
httpd_enable_homedirs
httpd_ssi_exec
allow_httpd_sys_script_anon_write
httpd_can_network_connect
httpd_can_network_connect_db

One of these Booleans is httpd_enable_cgi. As any Web administrator knows, CGI scripts can be potential security leaks—depending on the manner in which they are written and the use for which they are written. We frequently create Web servers that let people use CGI scripts to monitor and maintain our clients’ mail server queues—to delete messages, hold messages, etc. A security breach can expose the entire mail queue leaving our mail server(s) vulnerable.

To prevent CGI scripts from running on a server that does not require them to be executed, simply disable the httpd_enable_cgi Boolean (set the value of this Boolean to false). SELinux Access Controls will deny execution of CGI scripts and thus secure the server.

Using the seinfo tool discussed earlier, you can list all the available Booleans by issuing the following command:

[root@vbg services]# seinfo -b

All the Booleans inbuilt in the SELinux Targeted Policy shall be displayed.

The list of Booleans in the currently loaded policy can also be retrieved by the getsebool command. The -a option not only lists all Booleans similar to the seinfo -b command discussed earlier, but also the current value of those Booleans.

[root@vbg services]# getsebool -a
NetworkManager_disable_trans --> off
allow_console_login --> off
allow_cvs_read_shadow --> off
allow_daemons_dump_core --> on

The above output shows various Booleans and their values. To get the value of a particular Boolean, it may be specified as an argument to the getsebool command. To view the current value of thehttps_enable_cgi Boolean, issue the following command:

[root@vbg services]# getsebool httpd_enable_cgi
httpd_enable_cgi --> on

A system administrator on a system not requiring CGI script execution would want to set this Boolean to false (off). To modify the value of this Boolean we can use either the setsebool or the toggleseboolcommands.

To disable the httpd_enable_cgi Boolean, issue the following command:

[root@vbg services]# setsebool httpd_enable_cgi off

You can check the new value of the Boolean by again using the getsebool command described above:

[root@vbg services]# getsebool httpd_enable_cgi
httpd_enable_cgi --> off

The above change will affect the Boolean value in the currently loaded policy but will not remain after reboot. To make Boolean values persistent across reboots, use the -P option with the setsebool command:

[root@vbg services]# setsebool -P httpd_enable_cgi off

This will ensure that value of the httpd_enable_cgi Boolean has been set to off and will not change even after reboot.

[root@vbg services]# togglesebool httpd_enable_cgi
httpd_enable_cgi: active
[root@vbg services]# getsebool httpd_enable_cgi
httpd_enable_cgi --> on

A note of caution though: togglesebool only changes the “in memory” value of a Boolean. Changes made using the togglesebool command are not persistent across reboots.

As an exercise, I leave it to you to discover the Boolean that disables SELinux policy rules from applying to a particular service or daemon. In case of doubt, you can leave a comment below for an answer.

Booleans also help to understand the various protected daemons under the SELinux Targeted Policy.

PortCon

PortCon or Port Security Contexts are similar to File Security Contexts, but are applied to Network Sockets or ports. In a SELinux policy, access to various ports by subjects is critical. Portcon or Port Security Context Labels are based on protocol and port number(s)/range.

As an example, under the SELinux Targeted Policy, the httpd subject can only listen on standard ports. If the system administrators change the default ports from 80 (http) or 443 (https), they will need to add a newportcon in the SELinux policy to allow httpd to bind to this port.

To view the defined Port Security Contexts in the loaded SELinux policy, issue the following command:

[root@vbg ~]# seinfo -p

As you can see, the Port Context information contains the protocol, port and the security context. As an example, the http_port security contexts defined in the Red Hat Targeted policy are:

portcon tcp 80 system_u:object_r:http_port_t:s0
portcon tcp 443 system_u:object_r:http_port_t:s0
portcon tcp 488 system_u:object_r:http_port_t:s0
portcon tcp 8008 system_u:object_r:http_port_t:s0
portcon tcp 8009 system_u:object_r:http_port_t:s0
portcon tcp 8443 system_u:object_r:http_port_t:s0

As you can see, the first line of the output above labels the network Port 80 for TCP protocol with the security context:

system_u:object_r:http_port_t:s0

For the GUI initiated, policy details such as Booleans and Port Contexts can be viewed/modified by thesystem-config-selinux tool.

[root@vbg services]# system-config-selinux

Do execute this command under the X environment to view and comprehend the building blocks of a SELinux Security Policy.

NodeCon

Node Security contexts are labelled by the nodecon statements in an SELinux policy. They can be used to apply access control restrictions from various hosts/nodes in the network. An effective security policy for network access to services can be created by creatively applying node context access restrictions.

To list the default node contexts in the loaded SELinux policy, issue the following command:

[root@vbg ~]# seinfo -o

The output specifies security contexts assigned to various hosts:

[root@vbg ~]# seinfo -o
nodecon 0.0.0.0 255.255.255.255 system_u:object_r:inaddr_any_node_t:s0
nodecon 127.0.0.1 255.255.255.255 system_u:object_r:lo_node_t:s0
nodecon :: ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff system_u:object_r:unspec_node_t:s0
nodecon :: ffff:ffff:ffff:ffff:ffff:ffff:: system_u:object_r:compat_ipv4_node_t:s0
nodecon ::ffff:0000:0000 ffff:ffff:ffff:ffff:ffff:ffff:: system_u:object_r:mapped_ipv4_node_t:s0
nodecon fe80:: ffff:ffff:ffff:ffff:: system_u:object_r:link_local_node_t:s0
nodecon fec0:: ffc0:: system_u:object_r:site_local_node_t:s0
nodecon ff00:: ff00:: system_u:object_r:multicast_node_t:s0

Classes

Classes, or more specifically ‘Object Classes’, are the resources on which SELinux Access Restrictions are applied. Examples of Object Classes include file, dir and network sockets. An instance of an Object Class is called an Object.

To see the various Object Classes in the default loaded SELinux Policy, issue the following command:

[root@vbg ~]# seinfo -c

A file on your system, a network socket or a process—all of these are instances of Object Classes. A list of file related Object Classes in the default-loaded policy in my system is shown below:

   blk_file  - Block File
   chr_file  - Character File
   lnk_file  - Symbolic Links
   fifo_file - Named Pipes
   file      - Normal Files
   sock_file - UNIX domain sockets
   filesystem - Partitions etc
   dir        - Directories
   fd         - File Descriptors

Permissions

Permissions on Object Classes constitute the access control restrictions defined in a SELinux security policy. As you can guess, permissions relate to read/write and other fine grained controls. To list various permissions that can be applied to each of the Object Classes in the default loaded policy, issue the following command:
[root@vbg ~]# seinfo -c -x

As an example, the permissions that can be applied to an instance of the file object in the Targeted Policy loaded on my system, are:
file
      append
      create
      execute
      write
      relabelfrom
      link
      unlink
      ioctl
      getattr
      setattr
      read
      rename
      lock
      relabelto
      mounton
      quotaon
      swapon
      entrypoint
      execmod
      execute_no_trans

The above example means that processes (subjects) can be given permissions to append, create, execute, write, etc. Depending on the permissions specified to a particular subject, a successful access or denial will occur.

For example, you can specify that the httpd process can create a file in the /tmp/ folder, append to a file in the /var/log/ folder and only read from the /var/www/html/ folder.

If a newly installed Web application tries to create a file in the /var/www/html/ folder (assuming it is owned by the ‘apache’ user and has all the required DAC permissions using chmod/chown) it will still get a denial.

The above example clarifies how MAC restrictions prevent unauthorised tampering of data and secure your critical servers.

Attributes

Attributes group together types with similar properties. They make it easier to specify rules in a policy. For example, most applications (http, ftp, squid, mail) create log files. If the system administrator had to create individual rules for logrotate, appending and creating log files, it would involve a lot of repetitive work.

Once a type attribute is specified to a new object, permissions associated with that attribute are applied to the new object, saving a lot of repetitive work. To view a list of all attributes in the current loaded policy, issue the following command:
[root@vbg ~]# seinfo -a -x

You can see that log files are grouped together under the attribute @ttr1335:
@ttr1335
      amavis_var_log_t
      ccs_var_log_t
      ricci_var_log_t
      nscd_log_t
      var_log_ksyms_t
      ntpd_log_t
      sendmail_log_t
      var_log_t
        .
 .
 .

We will deal with categories, sensitivities, fs_use and genfscon in detail in subsequent articles in this series. In this article we have looked at more building blocks of SELinux security policies. The various basic building blocks of a SELinux Security Policy can be summarised as:

Users
Roles
Types
Booleans
Classes (Object Classes)
Permissions (on Object Classes)
Attributes
Port Contexts
Node Contexts


Access Control rules can be applied as per permissions assigned to classes. These rules can be summarised as:

Allow rules—to allow access
NeverAllow rules—to prohibit access


There are other rules as well—Type Transitions, AuditAllow, DontAudit, etc. In the next article we will explore how these rules are applied for access permissions to objects based on their Security Contexts.