Message-ID: <559EFC24.5050705@schaufler-ca.com>
Date: Thu, 09 Jul 2015 15:56:36 -0700
From: Casey Schaufler <casey@schaufler-ca.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: David Herrmann <dh.herrmann@gmail.com>,
        Stephen Smalley <sds@tycho.nsa.gov>
CC: Greg KH <gregkh@linuxfoundation.org>, Daniel Mack <daniel@zonque.org>,
        Djalal Harouni <tixxdz@opendz.org>,
        lkml <linux-kernel@vger.kernel.org>,
        LSM <linux-security-module@vger.kernel.org>,
        Paul Osmialowski <p.osmialowsk@samsung.com>,
        Paul Moore <paul@paul-moore.com>
Subject: Re: kdbus: credential faking
References: <559EBCC0.7040604@tycho.nsa.gov> <CANq1E4QH37+H3cbauN8LDRxp+Rsmtcn6CkLYCiV7XQrhm=qP9Q@mail.gmail.com>
In-Reply-To: <CANq1E4QH37+H3cbauN8LDRxp+Rsmtcn6CkLYCiV7XQrhm=qP9Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 4838
Lines: 101

On 7/9/2015 3:22 PM, David Herrmann wrote:
> Hi
>
> On Thu, Jul 9, 2015 at 8:26 PM, Stephen Smalley <sds@tycho.nsa.gov> 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.

That's fine in a discretionary access control model, but
not in a mandatory access control model. The decision on
trust of the "other" guy is never up to the process, it's
up to the mandatory access control policy.

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

Smack has to require CAP_MAC_ADMIN to allow a process to fake
Smack metadata. This is exactly what CAP_MAC_ADMIN is for.
Changing Smack metadata is considered a hugely dangerous activity.

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

I disagree with you strongly. Allowing a bus owner to fake connection
metadata is insane. If you're going to allow it it should frigging well
require privilege. You're allowing the program to *lie* about information
that an unsuspecting client may use to make important decisions. Go ahead
and cry "backward compatibility". Two wrongs don't make a right.

>
> Thanks
> David
>

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