dbus and Linux Containers

[Simon McVittie]

On 07/04/15 07:44, Kyungmin Park wrote:
>> I want the container to share the "outer" system bus also.

I'm not sure whether this can be secure in traditional D-Bus. It's
probably something kdbus can do securely.

As a general rule I think the current D-Bus policy language in
/etc/dbus-1/system.{conf,d/} is already too complicated, leading to
third-party applications accidentally making each other insecure
(CVE-2014-8148, CVE-2014-8156), and I am very wary about things that
would make it *more* complicated. This is not a definite "no", but
proposals for adding to that policy language do need to think about how
their ongoing maintenance cost can be minimized.

In particular, I am *very* reluctant to add more policy rules without
specific concrete use cases. "A process inside a container and a process
outside" is not a concrete use case; I'm looking for something more like
"a networking GUI inside a container talking to NetworkManager outside".

See also <https://bugs.freedesktop.org/show_bug.cgi?id=19593> and
<https://bugs.freedesktop.org/show_bug.cgi?id=50264#c1>.

>> DBus namespace policy can know current namespace by reading /proc/[current PID]/cpuset.

Is this vulnerable to the class of time of check / time of use attack
described in <https://bugs.freedesktop.org/show_bug.cgi?id=83499#c0>?

Linux has all sorts of namespaces which can differ between a container
and the "bare metal": filesystem namespace (chroot), mount namespace,
network namespace, and so on. Which one does this match up with? Or is
it a different one again?

>> This has 3 targets. target means where to apply dbus policies.
>> - private : current namespace only
>> - protected : current namespace + child namespaces + parent namespaces
>> - pulblic : all of namespacess

Is there any particular reason why you've gone for these three specific
models, and not (for instance) something based on assigning a name to
the namespace?

>> <policy namespace="protected">
>>     <allow send_type="method_call"/>
>>     <allow send_type="signal"/>
>>     <allow send_requested_reply="true" send_type="method_return"/>
>>     <allow send_requested_reply="true" send_type="error"/>
>> </policy>

How does this relate to user- and group-based policies? Let's say
user-based policies have boolean result U (true or false = allow or
deny), and namespace-based policies have result N. Is the overall result
U && N, or U || N?

If it's U || N, then it's a major security hole: it allows *any* method
call and *any* signal from inside a container to outside, including some
that really shouldn't be allowed (see also CVE-2014-8148).

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>