Re: dbus and Linux Containers

Simon McVittie <simon.mcvittie-ZGY8ohtN/[email protected]>
Newsgroups gmane.comp.freedesktop.dbus
Organization Collabora Ltd.
Message-ID <[email protected]>
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/>

_______________________________________________
dbus mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dbus
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.