Re: kdbus: credential faking

[David Herrmann]

Hi

On Thu, Jul 9, 2015 at 8:26 PM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:
> Hi,
>
> I have a concern with the support for faked credentials in kdbus, but
> don't know enough about the original motivation or intended use case to
> evaluate it concretely.  I raised this issue during the "kdbus for
> 4.1-rc1" thread a while back but none of the kdbus maintainers
> responded,

Sorry, some mails might have been gone unanswered in that huge thread.
Please feel free to ping us about anything we didn't comment on. See
below..

>            and the one D-BUS maintainer who did respond said that there
> is no API in dbus-daemon for faking client credentials, so this is not
> something inherited from dbus-daemon or required for compatibility with it.
>
> First, I have doubts as to whether there should be any way to fake the
> seclabel, no matter how "privileged" the caller.  Unless there is a
> clear use case for that functionality, I would prefer to see it dropped
> altogether.
>
> Second, IIUC, the ability to fake any portion of the credentials or pids
> is granted if the caller either has CAP_IPC_OWNER or owns the bus (uid
> match).  Clearly that isn't sufficient basis for seclabel faking, and it
> seems questionable as to whether it should be sufficient for faking any
> of the other credentials or pids.  Compare with e.g.
> net/core/scm.c:scm_check_creds() logic for faking credentials on a Unix
> domain socket, which requires CAP_SYS_ADMIN for faking pid, CAP_SETUID
> for faking any of the uid fields, and CAP_SETGID for faking any of the
> gid fields.
>
> Thanks for any light you can shed on the matter.

To be clear, faking metadata has one use-case, and one use-case only:
dbus1 compatibility

In dbus1, clients connect to a unix-socket placed in the file-system
hierarchy. To avoid breaking ABI for old clients, we support a
unix-kdbus proxy. This proxy is called systemd-bus-proxyd. It is
spawned once for each bus we proxy and simply remarshals messages from
the client to kdbus and vice versa.

With dbus1, clients can ask the dbus-daemon for the seclabel of a peer
they talk to. They're free to use this information for any purpose. On
kdbus, we want to be compatible to dbus-daemon. Therefore, if a native
client queries kdbus for the seclabel of a peer behind a proxy, we
want that query to return the actual seclabel of the peer, not the
seclabel of the proxy. Same applies to PIDS and CREDS.

This faked metadata is never used by the kernel for any security
decisions. It's sole purpose is to return them if a native kdbus
client queries another peer. Furthermore, this information is never
transmitted as send-time metadata (as it is, in no way, send-time
metadata), but only if you explicitly query the connection-time
metadata of a peer (KDBUS_CMD_CONN_INFO).

Regarding requiring CAP_SYS_ADMIN, I don't really see the point. In
the kdbus security model, if you don't trust the bus-creator, you
should not connect to the bus. A bus-creator can bypass kdbus
policies, sniff on any transmission and modify bus behavior. It just
seems logical to bind faked-metadata to the same privilege. However, I
also have no strong feeling about that, if you place valid points. So
please elaborate.
But, please be aware that if we require privileges to fake metadata,
then you need to have such privileges to provide a dbus1 proxy for
your native bus on kdbus. In other words, users are able to create
session/user buses, but they need CAP_SYS_ADMIN to spawn the dbus1
proxy. This will have the net-effect of us requiring to run the proxy
as root (which, I think, is worse than allowing bus-owners to fake
_connection_ metadata).

Thanks
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/