Loadable security modules for D-Bus

[Marcel Holtmann]

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