Loadable security modules for D-Bus

[Lennart Poettering]

On Mon, 09.01.12 18:17, Felipe Zimmerle (felipe.zimmerle at collabora.co.uk) wrote:

Heya,

> Then it raise another interesting question, having the "security
> hooks", no matter if dynamic loaded or not, the security
> implementations which will relay in those hooks will be hosted
> together with D-Bus or it can be something that is maintained under
> its own community? Not sure about the benefit of this, maybe it reduce
> the work to maintain a code which is not D-Bus specific by the D-Bus
> community.

This must be in D-Bus itself. It would be a very bad idea to standardize
on an internal security API for this and give any guarantees about its
stability -- which you'd have to do if such a project would live outside
of D-Bus proper.

This is also in your own interest since this insures that the apparmor
code doesn't bitrot that quickly. Like in the kernel, you want
everything upstream.

> Thiago's affirmative is correct, independent of been one or more
> supported frameworks, the distribution already know which security
> framework will be used and can compile the code to provide the
> mediations for "n" supported frameworks.  However in this case, at
> least "n+1" runtimes dependencies will be placed. For example, having
> support to SELinux depends on libselinux.so.1 and libaudit. By having
> support to
> SElinux and AppArmor we will have three dependencies:
> 
> * libselinux.so.1 (form libselinux1 at ubuntu)
> * libapparmor.so.1 (from libapparmor1 at ubuntu)
> * libaudit.so.1 (from audit-libs at fedora)
> 
> And so on, for each framework that a given distribution wants to
> support. It means that by installing D-Bus the user will have to have
> installed the libselinux and libapparmor and also libaudit,
> independent of been using one, two or none LSM mediations.

Yeah, well, if distros are crazy enough to support multiple parallel
security architectures it's their own problem. If they don't want the
deps this pulls in, then they should just compile the package twice, and
provide alternative packages for installation. But honestly, people who
do crack like this, deserve the pain this brings them, you don't have to
care.

In general I believe that the explosion of the test matrix which
multiple parallel compiled-in security archs would mean is a bad thing,
not a good thing.

> It is also important to note that depending on the security
> restrictions of a distribution, the startup of a given mediation could
> be mandatory, for example, without proper startup of the SELinux
> support the dbus-deamon won't start. This seems fair, although this is
> only a possibility since I don't have a real use case.

Not really. In Fedora our policy is that if selinux is off in the kernel
it is off in userspace too, and userspace should continue to work fine
without. No point in being more catholic than the pope.

> Regarding the to startup the things in systemd, I have the feeling
> that we want to startup the security policies/hooks/whatever before
> start any service, analogue of what we have on the network: the
> iptables/ebtables starts before the network interfaces.

We load the SELinux policy from within PID 1 in systemd, and do the
proper domain transition afterwards. THis is carefully optimized so that
we don't do more than necessary, don't leak any resources from before
the policy loading, and are as secure as needed. I am quite sure that
the right place to load global security policies is in the init process
itself, otherwise you'll necessarily get ordering problems and the
security policy would take only incomplete effect on PID 1 itself. (One
day, should Ubuntu come around and switch to systemd as well, I'd expect
that we'd add similar code like our SELinux loading logic for AppArmor
as well right into PID 1.)

Lennart

-- 
Lennart Poettering - Red Hat, Inc.