Re: [GIT PULL] kdbus for 4.1-rc1

[Daniel Mack]

Hi,

On 04/20/2015 08:01 PM, James Bottomley wrote:
> On Fri, 2015-04-17 at 16:27 -0400, Havoc Pennington wrote:

>> Do you have ideas on how to go about fixing it, whether in userspace
>> or kernel dbus?
> 
> Well, I've always suspected the solution would be for dbus to have a
> hierarchical namespace of its own with the default policy be pass
> message to parent namespace.  This would allow a container to determine
> which services were serviced outside and which inside the container (if
> you attach as a provider to the system bus in the container, that
> attachment supersedes the parent).
> 
> However, this doesn't solve the security problem: just because a
> container hasn't attached an interior provider doesn't mean it should be
> allowed complete access to all services provided from outside. This is
> the nasty problem because it involves some type of filter on busses
> which pass through containers.

Fair point, we've been thinking about that as well. What we implemented
for that is something we call 'custom endpoints', which is described in
kdbus.endpoint(7).

In short, an endpoint is an entry point to the bus. Each bus provides a
default endpoint node that enforces the bus-wide policy rules that
define which well-known names a peer may own, see, or talk to. Custom
endpoints can be added to carry additional policy rules for peers
connected through it, and redirecting a task or container to the custom
endpoint instead of the default one is as easy as bind-mounting the
node. systemd units actually have support for that since a while, which
is how we tested this feature. This implementation doesn't even add much
code to kdbus, because we do have the policy code around anyway, so
that's just a matter of which policy database to look at during runtime.

That said, it would actually even be easy to implement a way to allow
overriding names on custom endpoints too, so that services inside a
container can replace such that already exist on the bus. It's just that
so far, we haven't yet seen a use case for this.


Thanks,
Daniel


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/