SELinux is a security mechanism with a lot of ability to restrict user-space compromises in various useful ways. It has also generally been considered a heavyweight option that is not suitable for more resource-restricted systems like wireless routers. Undeterred by this perception, some OpenWrt developers are adding SELinux as an option for protecting the distribution, which targets embedded devices.

A mid-September blog post from Paul Spooren gives some of the background and status. In July, W. Michael Petullo picked up some older patches from Thomas Petazzoni. Petullo updated some of that work, including switching the tools from Python 2 to Python 3; he submitted the result as a pull request (PR) for OpenWrt. On August 30, that PR was merged; a related PR from Petazzoni adding some packages to support SELinux on the distribution was merged September 12.

The SELinux feature adds a mandatory access control (MAC) mechanism to the Linux kernel. Discretionary access control (DAC) is typified by the Unix read-write-execute permissions for files based on user and group IDs. While users can make changes to DAC permissions (e.g. chmod 777 ~), MAC policies generally cannot be overridden at run time.

The MAC policies used by SELinux allow administrators to specify which applications can have access to various objects in the system, primarily files and network resources. Instead of user-based permissions, these objects get assigned security contexts describing their scope. The policies then map which objects can access other objects that have specific contexts, thus they could allow a web server to only be able to access files under a certain directory, to only be able to bind to specific network port numbers, and to be unable to initiate outbound connections. In order to change those restrictions, the root user would need to install different policy at boot time or relabel objects to have contexts that allow them to be accessed. Absent a kernel compromise, services and other processes restricted in this way should not be able to reach outside of the places where their access is confined to.

Security labels are the way that SELinux determines the context of a file object; that information is stored as an extended attribute on the files themselves. Because they live in the protected security extended attribute namespace, they cannot be changed by regular users. So the refpolicy package will label the files with their context as the image is being built.

Switching a distribution to use SELinux involves more than just enabling a kernel feature, however. As the blog post describes, the build system needed to be configured so that kernels supporting SELinux can be created. Turning on options to enable SELinux (CONFIG_KERNEL_SECURITY_SELINUX) and to allow security labels in the root filesystem (CONFIG_TARGET_ROOTFS_SECURITY_LABELS) will automatically select the refpolicy package, which will put the security labels on the files in the squashfs (or F2FS) root filesystem.

In order for SELinux to apply its policies, processes started on the system need to have a security context associated with them. That is the responsibility of the init process, but, currently, the init used for OpenWrt, procd, does not set contexts on the processes that it starts. Work on that is planned. Administrators also need to be able to examine the context associated with files, processes, and other objects, which is done using the -Z switch to utilities like ls and ps. Like most embedded distributions, OpenWrt uses BusyBox; a custom busybox-selinux package was created that configures BusyBox to add the needed support.

The initial policy being used is the reference policy from the upstream SELinux project; "it has not been tuned specifically for OpenWrt", Petazzoni said. There are plans to tweak that policy based on the specific needs of OpenWrt. There is still more to be done, of course, but much of the underlying infrastructure has been merged into OpenWrt at this point. As the blog post shows, it is possible to launch a virtual machine with an SELinux-enabled OpenWrt image and see contexts, labels, and so on. Adding support to procd for setting contexts will provide for much of the remaining needed pieces for basic support in OpenWrt.

In general, SELinux has not been that much of a factor in the embedded Linux world. An obvious counterexample, though, is SELinux on Android, which started small in the Android 4.x series but has since grown to be an integral part of the security landscape for the phone distribution. But embedded SELinux has been investigated for longer still, though the resource requirements have generally kept it to higher-end devices. OpenWrt supports a wide range of devices, so SELinux might just find a home in some of them.

The security landscape for home routers is generally pretty bleak; adding SELinux protections for OpenWrt can only help with that picture. Also, SELinux is perhaps a better fit for a router distribution than it is for, say, Fedora systems, where the software being run is changing more frequently and needs more tweaks to the SELinux policy in order to continue to function. As elsewhere, of course, SELinux is no panacea, but it could certainly improve the security for home routers and the like.