Simplicity is a form of art...

Filtering network access per application

Iptables (and the successor nftables) is a powerful packet filtering system in the Linux kernel, able to create advanced firewall capabilities. One of the features that it cannot provide is per-application filtering. Together with SELinux however, it is possible to implement this on a per domain basis.

SELinux does not know applications, but it knows domains. If we ensure that each application runs in its own domain, then we can leverage the firewall capabilities with SELinux to only allow those domains access that we need.

Don't confuse SELinux with its policy

With the increased attention that SELinux is getting thanks to its inclusion in recent Android releases, more and more people are understanding that SELinux is not a singular security solution. Many administrators are still disabling SELinux on their servers because it does not play well with their day-to-day operations. But the Android inclusion shows that SELinux itself is not the culprit for this: it is the policy.

Loading CIL modules directly

In a previous post I used the secilc binary to load an additional test policy. Little did I know (and that's actually embarrassing because it was one of the things I complained about) that you can just use the CIL policy as modules directly.

With this I mean that a …

Restricting even root access to a folder

In a comment Robert asked how to use SELinux to prevent even root access to a directory. The trivial solution would be not to assign an administrative role to the root account (which is definitely possible, but you want some way to gain administrative access otherwise ;-)

Restricting root is one of the commonly referred features of a MAC (Mandatory Access Control) system. With a well designed user management and sudo environment, it is fairly trivial - but if you need to start from the premise that a user has direct root access, it requires some thought to implement it correctly. The main "issue" is not that it is difficult to implement policy-wise, but that most users will start from a pre-existing policy (such as the reference policy) and build on top of that.

Intermediate policies

When developing SELinux policies for new software (or existing ones whose policies I don't agree with) it is often more difficult to finish the policies so that they are broadly usable. When dealing with personal policies, having them "just work" is often sufficient. To make the policies reusable for distributions (or for the upstream project), a number of things are necessary:

• Try structuring the policy using the style as suggested by refpolicy or Gentoo
• Add the role interfaces that are most likely to be used or required, or which are in the current draft implemented differently
• Refactor some of the policies to use refpolicy/Gentoo style interfaces
• Remove the comments from the policies (as refpolicy does not want too verbose policies)
• Change or update the file context definitions for default installations (rather than the custom installations I use)

Where does CIL play in the SELinux system?

SELinux policy developers already have a number of file formats to work with. Currently, policy code is written in a set of three files:

• The .te file contains the SELinux policy code (type enforcement rules)
• The .if file contains functions which turn a set of arguments into blocks of SELinux policy code (interfaces). These functions are called by other interface files or type enforcement files
• The .fc file contains mappings of file path expressions towards labels (file contexts)

These files are compiled into loadable modules (or a base module) which are then transformed to an active policy. But this is not a single-step approach.

Testing with permissive domains

When testing out new technologies or new setups, not having (proper) SELinux policies can be a nuisance. Not only are the number of SELinux policies that are available through the standard repositories limited, some of these policies are not even written with the same level of confinement that an administrator might expect. Or perhaps the technology to be tested is used in a completely different manner.

Without proper policies, any attempt to start such a daemon or application might or will cause permission violations. In many cases, developers or users tend to disable SELinux enforcing then so that they can continue playing with the new technology. And why not? After all, policy development is to be done after the technology is understood.

Use change management when you are using SELinux to its fullest

If you are using SELinux on production systems (with which I mean systems that you offer services with towards customers or other parties beyond you, yourself and your ego), please consider proper change management if you don't do already. SELinux is a very sensitive security subsystem - not in the sense …

CIL and attributes

I keep on struggling to remember this, so let's make a blog post out of it ;-)

When the SELinux policy is being built, recent userspace (2.4 and higher) will convert the policy into CIL language, and then build the binary policy. When the policy supports type attributes, these are …

SELinux is great for enterprises (but many don't know it yet)

Large companies that handle their own IT often have internal support teams for many of the technologies that they use. Most of the time, this is for reusable components like database technologies, web application servers, operating systems, middleware components (like file transfers, messaging infrastructure, ...) and more. All components that are …