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.

more ...

My application base: Obnam

It is often said, yet too often forgotten: taking backups (and verifying that they work). Taking backups is not purely for companies and organizations. Individuals should also take backups to ensure that, in case of errors or calamities, the all important files are readily recoverable.

For backing up files and directories, I personally use obnam, after playing around with Bacula and attic. Bacula is more meant for large distributed environments (although I also tend to use obnam for my server infrastructure) and was too complex for my taste. The choice between obnam and attic is even more personally-oriented.

more ...

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.

more ...

Switching to Pelican

Nothing beats a few hours of flying to get things moving on stuff. Being offline for a few hours with a good workstation helps to not be disturbed by external actions (air pockets notwithstanding).

Early this year, I expressed my intentions to move to Pelican from WordPress. I wasn't actually unhappy with WordPress, but the security concerns I had were a bit too much for blog as simple as mine. Running a PHP-enabled site with a database for something that I can easily handle through a static site, well, I had to try.

more ...


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.

more ...

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)
more ...

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.

more ...

Live SELinux userspace ebuilds

In between courses, I pushed out live ebuilds for the SELinux userspace applications: libselinux, policycoreutils, libsemanage, libsepol, sepolgen, checkpolicy and secilc. These live ebuilds (with Gentoo version 9999) pull in the current development code of the SELinux userspace so that developers and contributors can already work with in-progress code developments as well as see how they work on a Gentoo platform.

more ...