Listing conditional policy support_SELinux Cookbook-QQ阅读男生科幻网

上QQ阅读APP看书，第一时间看更新

Listing conditional policy support

The first configurable aspect of the SELinux web server domain policy is its wide use of SELinux Booleans. Through these Booleans, additional policy rules can be selectively enabled or disabled. In this recipe, we'll look at the Booleans and see how these can be toggled.

How to do it…

In order to list the conditional policy support, execute the following steps:

Request the list of all SELinux Booleans and selectively show those starting with httpd_:
```
~# getsebool –a | grep httpd_
```
To get a short description together with the Booleans, we can use semanage:
```
~# semanage boolean –l | grep httpd_
```

If the description of a Boolean isn't sufficient, we can ask the SELinux utilities to display the SELinux rules that will be enabled (or disabled) if the Boolean is set:

~# sesearch –b httpd_enable_ftp_server –AC
Found 3 semantic av rules:
DT allow httpd_t httpd_t : capability net_bind_service ; [ httpd_enable_ftp_server ]
DT allow httpd_t ftp_port_t : tcp_socket { recv_msg send_msg name_bind } ; [ httpd_enable_ftp_server ]
DT allow httpd_t ftp_server_packet_t : packet { send recv } ; [ httpd_enable_ftp_server ]

How it works...

Conditional SELinux policy support is provided through SELinux Booleans. These are configurable parameters (with a true/false value), which an administrator can enable or disable using the setsebool or semanage boolean command.

With the getsebool command, we request an overview of all SELinux Booleans. Recent policies have a few hundred Booleans assigned, but luckily most Booleans follow one of the two following naming conventions that make filtering easier:

A Boolean starts with allow_ or use_
A Boolean starts with the SELinux policy module prefix

Booleans that start with allow_ or use_ are considered global Booleans and will usually affect multiple SELinux policy modules. A good example for such a Boolean is allow_execmem, which enables several domains to execute code stored in writable memory rather than read-only memory (this is a harmful, but sometimes unavoidable memory permission setting).

Most, if not all other Booleans start with the SELinux policy module prefix that they are applied to. For the web server, this is httpd_ (even though the policy is called apache, the httpd_ prefix is chosen because the policy can apply directly on various web servers, not only on the Apache HTTPd).

When we use the semanage boolean command, a short description is provided for the Booleans. This description is obtained from an XML file called policy.xml, which can be found at /usr/share/selinux/devel/. The XML file is generated during the build of the base SELinux policy.

The most accurate description of a Boolean, however, is the set of rules that it would trigger when enabled or disabled. This is where the sesearch command comes into play.

As can be seen from the example, Booleans will trigger one or more allow rules. The prefix to the sesearch output tells us whether a shown rule is active if the Boolean is true (T) or false (F), and if the rule is currently enabled (E) in the policy or disabled (D).

A nice trick when querying the SELinux policy using sesearch is to ask for Boolean-managed rules as well (regardless of whether they are currently enabled or disabled). This can be accomplished by adding the –C option (which is the short option for --show_cond). For instance, to find the transitions of the newrole_t domain, the following command can be used:

~# sesearch –s newrole_t –c process –p transition –AC
Found 5 semantic av rules:
 allow newrole_t newrole_t : process { … };
 allow newrole_t chkpwd_t : process transition;
 allow newrole_t updpwd_t : process transition;
EF allow newrole_t userdomain : process transition ; [ secure_mode ]
DT allow newrole_t unpriv_userdomain : process transition ; [ secure_mode ]