Loadable security modules for D-Bus

[Marcel Holtmann]

Hi John,

> >>> 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.
> > 
> > so if we follow this and accept the fact that method or interface based
> > security model for D-Bus is basically to inflexible and thus useless,
> > the recommendation should be to remove SELinux support from D-Bus bus
> > daemon.
> > 
> That is a big if.  I would disagree with the assertion and just because
> one solution is inflexible does not mean that they all have to be.

you are clearly not getting my point here.

> > Coming to think about it, I really prefer a method where systemd is able
> > to load a system bus owning security policy based on either UID or
> > cgroup into the dbus-daemon and that is it. And don't we already have
> > the system bus name in the unit file anyway for autostart purposes?
> > 
> > Everything else is up to the daemon to figure out by itself. Especially
> > since the daemon knows way better anyway than some weird global security
> > policy.
> > 
> I would argue it doesn't, and it really should be coordinating with the
> security policy

And how does user interaction fit into your model here? And more
important, how do you wanna make user confirmation/interaction work?

Regards

Marcel