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.
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.
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.
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 …
After a post about D-Bus comes the inevitable related post about SELinux with D-Bus.
Some users might not know that D-Bus is an SELinux-aware application. That means it has SELinux-specific code in it, which has the D-Bus behavior based on the SELinux policy (and might not necessarily honor the "permissive …
Today we analyzed a weird issue one of our SELinux users had with their
system. He had a denial when calling audit2allow, informing us that
sysadm_t had no rights to read the SELinux policy. This is a known
issue that has been resolved in our current SELinux policy repository
tl;dr: Some (
-9999) policy ebuilds now have
USE support for
building in (or leaving out) SELinux policy statements.
One of the "problems" I have been facing since I took on the maintenance of SELinux policies within Gentoo Hardened is the (seeming) inability to make a "least privilege" policy that …
A few months ago, I wrote a small script that aids in the creation of
new SELinux policy packages. The script is on the
itself, in the
gentoo/ subdirectory, and is called
The reason for the script is that there are a number of steps to perform …
As you are probably aware, Gentoo uses the reference
policy as its base for
SELinux policies. Yes, we do customize it and not everything is already
pushed upstream (for instance, our approach to use
customizable types to further restrict user application access has been
sent up for comments …
After 9 posts, it's time to wrap things up. You can review the final results online (incron.te, incron.if and incron.fc) and adapt to your own needs if you want. But we should also review what we have accomplished so far...
We built the start of an entire …