dbus and Linux Containers

[유성배]

>> 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".

The use case that I thought is similar to your example.

We want to use container for protecting application environment.
But, we don't want that every services don't need to run in container :
Isolated services and applications should be ran in container.
But device-wide services such as ConnectionManager and DeviceManager don't
need to this.

>> 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?

Sorry for my mis-used word. DBus container policy is more exact.
LXC(LinuX container) is a combination of namespaces and cgroups.
cgroups cpuset is used for grouping tasks of same container in LXC.
Dbus container policy just uses cgroups cpuset(/proc/[current PID]/cpuset)
for distinguish container name.

>> 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>?

If process in container can control cgroups, it will be vulnerable.
So, DBus container policy need a assumption that process in container must
not control cgroups.
Even though not using DBus container policy, it is dangerous that process
can control cgroups of another container.
It is simple to permit this by using capabilities and mount namespaces in
LXC.

>> 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?

In the use case that I mentioned, it is important to limit range to deliver
dbus messages.
Device-wide services want to deliver dbus messages to all containers.
And isolated services don't want to deliver to inside of other container.

In that case, it is too much complicated to assigning a name of container.
Device-wide services should add a each allow policy in /etc/dbus-
1/system.{conf.d/} for all containers.
It makes policy files to be complicated.

>> 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?

The overall result is U && N. U || N will be a major security hole as you
mentioned.


Thanks,
Best regards, Sungbae Yoo.