Why we do confine Firefox

If you're a bit following the SELinux development community you will know Dan Walsh, a Red Hat security engineer. Today he blogged about CVE-2015-4495 and SELinux, or why doesn't SELinux confine Firefox. He should've asked why the reference policy or Red Hat/Fedora policy does not confine Firefox, because SELinux is, as I've mentioned before, not the same as its policy.

In effect, Gentoo's SELinux policy does confine Firefox by default. One of the principles we focus on in Gentoo Hardened is to develop desktop policies in order to reduce exposure and information leakage of user documents. We might not have the manpower to confine all desktop applications, but I do think it is worthwhile to at least attempt to do this, even though what Dan Walsh mentioned is also correct: desktops are notoriously difficult to use a mandatory access control system on.

more ...

Can SELinux substitute DAC?

A nice twitter discussion with Erling Hellenäs caught my full attention later when I was heading home: Can SELinux substitute DAC? I know it can't and doesn't in the current implementation, but why not and what would be needed?

SELinux is implemented through the Linux Security Modules framework which allows for different security systems to be implemented and integrated in the Linux kernel. Through LSM, various security-sensitive operations can be secured further through additional access checks. This criteria was made to have LSM be as minimally invasive as possible.

more ...

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