Loadable security modules for D-Bus

[Lennart Poettering]

On Mon, 09.01.12 17:14, Marcel Holtmann (marcel at holtmann.org) wrote:

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

I tend to agree with this. I think the per-method security policy is way
to baroque. Service-based access should suffice, and the emphasis be put
on PK for everything else.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.