A collection of notes on SElinux

This collection is work in progress. It starts from introductory concepts and moves to the development of modules. There are layers of jargon and terminology in SElinux, but once you cut though these, the concepts underneath are often straight forward.

Notes on SElinux: initial concepts

Here are some of my notes on using SElinux (Security Enhanced linux) in fedora. By default in fedora (including and above core 4) SElinux is installed and a targeted policy is active. The targeted policy is where the default (non-SElinux) linux security is followed, but a few targeted programs have limits imposed on what they can do (I'll talk more about the targeted policy in later notes). There is a lot of terminology in the SElinux world, and this can make some of the quite intuitive concepts much less intuitive. SElinux can be a very useful security tool, and it is worth looking at what it can do.

Notes on SElinux: configuration

In fedora the SElinux set-up and configuration files are in /etc/selinux. Most of these are created/modified using SElinux administration tools such as "semanage" (we will look at these tools later). In addition to the configuration files governing the overall SElinux set-up, the policy rules can also be tweaked without needing to even look at the policy rules themselves. This is done through booleans, on-off switches that modify how a particular rule or set of rules in the active policy work.

Notes on SElinux: policies and modules

A policy for SElinux contains all the definitions for user identities, object types, process types, and roles. It also contains all the rules that specify how types interact (see the notes on type enforcement). The ability to dynamically change or introduce new policy components into the current system policy is an important recent feature of SElinux. There are now self-contained policy modules that can be loaded and which safely interact with the currently active policy. In fact, loaded modules become part of the current active policy.

Notes on SElinux: tools

There are a number of tools, both command line and graphical, that allow analysis, configuration, and changes to the running SElinux policy. I will summarise some of the most useful ones here. For further and more complete information, most have a man page. Many of these tools require appropriate privileges for accessing the SElinux configuration, policies and internals (e.g. usually root).

An SElinux module (1): types and rules

In fedora the resources and files necessary for building new modular policies are in the devel directory under /usr/share/selinux/. This directory and all the files required for module development come from the fedora selinux-policy-devel rpm.

As an example, I am going to develop a policy module for the lighttpd http server, which is a "light" apache-like server.

An SElinux module (2): file contexts and labelling

Having created a number of file types in part (1), we need to specify which parts of the filesystem are labelled with these types. The file types created were lighttpd_exec_t, lighttpd_config_t, lighttpd_modules_t, lighttpd_log_t and lighttpd_var_run_t. All of these types belong to files in very specific locations. For example, the lighttpd_exec_t type should label only the lighttpd executable (at /usr/sbin/lighttpd).

An SElinux module (3): interfaces

When creating the type enforcement rules for lighttpd (part 1) we used a lot of interfaces to other modules and policies. For example, we used the interface provided by the apache module to allow the lighttpd module access to all the same system web content (labelled with the type httpd_sys_content_t). This, and all the other interfaces we used, not only made this module easier to write but also make it robust to changes in any of the other modules.

An SElinux module (4): building and debugging

Having written the type enforcemnt, interface and file context files the next step is to put them together into a single policy module. This is done by "compiling" the three files into a single policy file that can be inserted into the complete SElinux policy. Once inserted, the process of debugging the module begins.

Notes on SElinux: Multi-Category Security

SElinux, and Mandatory Access Control (MAC) in general, is complex. In some sense it mirrors the complexity of the underlying software and system it is protecting. It is not very system user friendly, and it is certainly not end user friendly. Adding additional complexity such as Multi-Level Security (MLS) makes the situation considerably worse. Most system administrators would like their end users not even to know MAC is present.

SElinux and alternative ssh ports

It is quite common, and can be very effective, to use alternative/non-standard ssh ports to avoid port scans. Normally ssh listens for incoming connections on port 22. As this is its published port number it is easy for people and software to connect to this port and try random or typical user names and passwords (e.g. "root" user with password "password"). To make this more difficult ssh can be set up to listen to a non-standard port so that only those who know which port it is can connect quickly and easily. This technique is one I have used successfully for many years. With the release of Fedora 9 and the expansion of its SElinux policy, getting ssh to listen on alternative ports requires an additional step.