The interface names used to simplify policy development can be freely chosen. However, the reference policy itself uses a naming convention to try and structure the names used so that the SELinux policy developers can easily find the interfaces they need—if they exist—and give an unambiguous name to an interface they want to create.
The naming convention for the reference policy is available online at http://oss.tresys.com/projects/refpolicy/wiki/InterfaceNaming.
In this recipe, we'll do a pen-and-paper exercise to see how the naming convention works. In the example, we will create interface names for three situations:
To read all logfiles
To connect to the HTTP port over TCP
To not audit getting the attributes of user home directories
First we need to figure out the file types that are involved in the situations:
Generic logfiles are
var_log_t(as can be seen by querying the label of/var/log/itself):~$ ls -dZ /var/log drwxr-xr-x. root root system_u:object_r:var_log_t:s0 /var/log
When we deal with all logfiles, we can safely assume this is handled by an SELinux attribute. Let's look at the attributes for the generic
var_log_ttype:~$ seinfo –tvar_log_t –x var_log_t file_type non_security_file_type mountpoint non_auth_file_type logfile
The
logfileattribute looks like an interesting hit. We can now grep through the policy sources to figure out which SELinux policy modules handle thelogfileattribute, or usesefindif(assuming that there are interfaces defined that handle this attribute):~$ sefindif 'attribute logfile' system/logging.if: interface(`logging_log_file',` …
For the logfiles example, the module we need is called
loggingas can be seen from thesefindifoutput. Similarly, we will find that for the HTTP port, the module iscorenet, and home directories areuserdom.
Next, we check whether there is a modifier. The first two situations have no specific modifier (all the actions are regular verbs). The last example has one: do not audit. In the SELinux policy language, this is known as a
dontauditstatement.Now, let's look at the verbs involved. This is mostly based on experience, but the situations show that there is a huge correlation between the verbs and the eventually chosen
refpolicyname (which usually uses SELinux permission names):In the first situation, this is
readThe second one has
connect over TCP, which is translated intotcp_connectThe last situation has
getting the attributes, so it is translated asgetattr
Finally, let's look at the object that is being referenced:
In the first situation, this is
all logfiles, which we will nameall_logsIn the second situation, this is
HTTP port, so we will namehttp_portThe third situation has
user home directories, so we will nameuser_home_dirs
Combining this gives us the following interface names:
Read all logfiles:
logging_read_all_logsConnect to the HTTP port over TCP:
corenet_tcp_connect_http_portDo not audit getting the attributes of user home directories:
userdom_dontaudit_getattr_user_home_dirs
The naming convention that the reference policy uses is not mandated in a technical manner. Just like with coding styles, naming conventions are made so that collaboration is easier (everyone uses the same naming convention) and searching through the large set of interfaces can be directed more efficiently.
Using the proper naming convention is a matter of exercise. If uncertain, ask around in #selinux on irc://irc.freenode.net or on the reference policy mailing list.
Take some time to look through the interface files available at /usr/share/selinux/devel/include/. Next, for the more standard permission-based interface names, there are also interface names used for templates and type assignation.
For instance, there is a template called apache_content_template. Through it, additional SELinux types and permissions (used for web applications) are created in one go. Similarly, there is an interface called apache_cgi_domain that marks a particular type as being a domain that can be invoked through a web servers' CGI support.
Besides the naming convention, the reference policy also has a style guide available at http://oss.tresys.com/projects/refpolicy/wiki/StyleGuide. Like the naming convention, this is purely a human aspect for improved collaboration—there is no consequence of violating the coding style beyond the changes that might not be accepted in the upstream repositories.