Loadable security modules for D-Bus

[John Johansen]

On 01/10/2012 02:14 AM, Marcel Holtmann 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 wouldn't be opposed to that, but I don't see it happening either

> 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.
> 
Static configuration has its place, but who says that a security module
has to be enforcing a static configuration, there are a range of security
solutions

> 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.
> 
I would disagree

> Everything else should be left up to the daemon and enforced dynamically
> via PolicyKit or similar technologies.
> 
again I would have to disagree

> Regards
> 
> Marcel
> 
> 
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus