Block access to dbus

[HulaHoopWhonix]

A very serious vulnerability was discovered where dbus-daemon used ipc message as format string. Subgraph's Oz sandbox say they are not affected since they block dbus access to isolated processes. I recommend you do the same if not already.

https://bugs.freedesktop.org/show_bug.cgi?id=98157

/cc @adrelanos

[alexlarsson]

We don't block dbus access, instead we run a filtering dbus proxy that all dbus calls go through.

However, it looks like this may affect us still. We do allow apps to send messages and signals directly to the "org.freedesktop.DBus" name on the bus, which seems to be the issue here.

/cc @smcv you know this best, do we have a problem here?

[smcv]

There are two things you could mean by "D-Bus access": the session bus and the system bus. The session bus is per-uid; the worst-case vulnerability there is escalating from sandboxed uid 1000 (or whatever your uid is) to un-sandboxed uid 1000. The system bus is per-system (whatever "system" means, originally per-kernel, but now more likely per-OS-container), so the worst-case vulnerability there is escalating from sandboxed uid 1000 to a different un-sandboxed uid.

Either way, the correct solution to this is to fix the host's dbus-daemon. dbus-daemon is meant to be safe to use as a privilege boundary; that's why we handled the format string issue (fd.o bug 98157) as a security vulnerability, and not just a bug. (I must admit I was mainly thinking of the system bus and not the session bus when I treated that as a vulnerability, though.)

98157 is not exploitable unless you own the name org.freedesktop.systemd1 (or unless you have a dbus-daemon where CVE-2015-0245 was never fixed in the year and a half since it was fixed upstream, which for some reason includes several Ubuntu releases). Am I correct in saying that Flatpak mediates D-Bus name ownership (RequestName messages) already, so it won't let contained processes do that?

On the system bus (where the worst-case impact of 98157 is privilege escalation between uids, not just a sandbox bypass for the unprivileged uid), org.freedesktop.systemd1 can only be owned by root, so uid 1000 isn't going to be allowed to do that even if the IPC message isn't filtered out.

block dbus access to isolated processes

It would be fine for Flatpak to optionally block D-Bus access via a flag in the app's metadata, but unconditionally blocking the session bus altogether would break the majority of the apps that are packaged this way, so, no.

The situation on the system bus is less clear-cut. @alexlarsson, is the system bus treated the same at the moment, with filtering? (Note that anything on the system bus that is not safe for random users to call is already meant to be access-controlled, with missing access-controls being a security vulnerability whether you have Flatpak or not.)

We do allow apps to send messages and signals directly to the "org.freedesktop.DBus" name on the bus

I would recommend allowing exactly those messages that you know to be OK, and forbidding the others.

That's:

• RequestName (filtered according to what names you want to allow it to own)
• ReleaseName (can be unconditional)
• StartServiceByName (filtered so it can start exactly those names it would be allowed to talk to)
• AddMatch (either filtered, or filtering the signals coming back instead)
• RemoveMatch

and depending on your security model (the extent to which it is considered to be acceptable that apps in the sandbox can learn about apps outside), perhaps:

• ListQueuedOwners
• ListNames
• ListActivatableNames
• NameHasOwner
• GetNameOwner
• GetConnectionCredentials and its deprecated subsets GetConnectionUnixUser, GetConnectionUnixProcessID and GetConnectionSELinuxContext (also GetAdtAuditSessionData but as far as I know that one is Solaris-specific)
• GetId
• the whole Stats interface (but this is something that only developers should be using anyway, so maybe it can be hidden behind the same "developer stuff" boolean as e.g. ptrace)

You certainly don't want to allow:

• UpdateActivationEnvironment
• Monitoring.BecomeMonitor (again, a developer feature)
• ActivationFailure unicast signal (the one that had fd.o bug 98157, as it happens, but there's no reason a Flatpak would ever legitimately send this anyway)

[alexlarsson]

So, currently both system and session bus are accessible, but via a proxy. In this proxy you have per-name rules (that actually also affects unique names that own the corresponding names). On these you can have permissions NONE, SEE, TALK & OWN. Additionally we do special filtering on METHOD CALLS (but not at at signals atm) to the name org.freedesktop.DBus, iface org.freedesktop.DBus.

Looking at your list I see a few issues we need to fix:

• We're looking for BecomeMonitor on org.freedesktop.DBus, not org.freedesktop.DBus.Monitoring. In fact, we're broadly allowing everything to org.freedesktop.DBus that doesn't target the org.freedesktop.DBus interface. We should problably whitelist them instead.
• We're only filtering method calls to the bus, not unicast signals.

[alexlarsson]

With that i belive we're secure in general and in particular the unicast filtering fixes the specific worry above.

[smcv]

b337c95 looks good to me.