Starting the kdbus discussions

[Lennart Poettering]

On Thu, 02.01.14 11:23, Marc Deslauriers (marc.deslauriers at canonical.com) wrote:

> Well, as I said before, we've added AppArmor support to the existing security
> hooks that are there for SELinux. Although dbus-daemon didn't use policy files
> for the session bus, the security support was already there, and we are
> currently using it.
> 
> I'm not sure I understand the suggestion to use Policykit. When confining an
> application, you want to block all access to the objects available on the
> session bus, and, depending on the rights you want to grant to the specific
> application, selectively allow certain paths, interfaces, method names. Using
> Policykit for this would mean every single application that offered methods on
> the session bus would need to integrate with policykit and perform its own
> access control. I'm not even sure how you would do that if you have multiple
> untrusted applications running.

Well, it's generally not applications talking to other
applications. It's mostly applications talking to desktop services. And
those I believe should just come with PolicyKit hooks. I am pretty sure
having apps talk to other apps is something a good sandbox should
prohibit entirely.

> I think kdbus needs to gain payload parsing capabilities for proper LSM
> integration in order to properly confine untrusted applications.

I am sorry, but to make this very clear: this is explicitly not an
option. There will not be a payload parser for kdbus in the kernel, as
long as the four developers who are working on it have any say. The
entire design is based on the concept that the payload is irrelevant to
the kernel, and routing is done only according to the metadata we
attach. This is a fundamental design decision of kdbus, and the four of
us (Kay, Daniel, Greg and I) will refuse this.

If you require this feature, then kdbus is explicitly not something you
should look into. Ubuntu has to find a different solution there, sorry.

Lennart

-- 
Lennart Poettering, Red Hat