Re: kdbus: credential faking

[Stephen Smalley]

On 07/09/2015 06:22 PM, David Herrmann wrote:
> 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.

Is this truly necessary?  Can't the distributions just update the client
side libraries to use kdbus if enabled and be done with it?  Doesn't
this proxy undo many of the benefits of using kdbus in the first place?

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

I guess I don't understand the difference.  Is there a separate facility
for obtaining the send-time metadata that is not subject to credential
faking?

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

Applications have a reasonable expectation that credentials supplied by
the kernel for a peer are trustworthy.  Allowing unprivileged users to
forge arbitrary credentials and pids seems fraught with peril.  You say
that one should never connect to a bus if you do not trust its creator.
 What mechanisms are provided to allow me to determine whether I trust
the bus creator before connecting?  Are those mechanisms automatically
employed by default?
--
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/