Loadable security modules for D-Bus

Marcel Holtmann marcel at holtmann.org
Mon Jan 9 17:14:09 PST 2012


Hi Lennart,

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

maybe a a little bit off topic. However my personal take on this is that
the D-Bus bus daemon part should be moved into the kernel and then
hooked up with LSM. Then everybody can do whatever they please with
their security frameworks.

I do question the general usefulness of D-Bus security. I think it is
pretty clear by now that static configuration is not really useful
anyway. So not doing this at all and even getting rid of SELinux support
might be a good idea.

The only security related policy should be which daemon can own which
system bus name. And this might be a good option to be enforced by a
systemd unit file for that service.

Everything else should be left up to the daemon and enforced dynamically
via PolicyKit or similar technologies.

Regards

Marcel




More information about the dbus mailing list