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, 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.
Hi
On Thu, Jul 9, 2015 at 8:26 PM, Stephen Smalley <[email protected]> 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
On 7/9/2015 3:22 PM, David Herrmann wrote:
> Hi
>
> On Thu, Jul 9, 2015 at 8:26 PM, Stephen Smalley <[email protected]> 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
>
Hi
On Fri, Jul 10, 2015 at 12:56 AM, Casey Schaufler
<[email protected]> wrote:
> On 7/9/2015 3:22 PM, David Herrmann wrote:
>> 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.
Exactly. So LSMs are free to use a hook to limit faking other user's
credentials. But why does that have to affect the default (which, in
the case of kdbus, is a dac model)?
>> 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.
I'm totally fine with dropping support to fake seclabels, if LSM
developers see no need for it. I, certainly, will not insist on it.
With that in mind, I'd prefer if we limit this discussion to faking CREDS/PIDS.
>> 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. [...]
Ok.
Thanks
David
On 07/09/2015 06:22 PM, David Herrmann wrote:
> Hi
>
> On Thu, Jul 9, 2015 at 8:26 PM, Stephen Smalley <[email protected]> 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?
On 07/10/2015 05:05 AM, David Herrmann wrote:
> Hi
>
> On Fri, Jul 10, 2015 at 12:56 AM, Casey Schaufler
> <[email protected]> wrote:
>> On 7/9/2015 3:22 PM, David Herrmann wrote:
>>> 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.
>
> Exactly. So LSMs are free to use a hook to limit faking other user's
> credentials. But why does that have to affect the default (which, in
> the case of kdbus, is a dac model)?
>
>>> 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.
>
> I'm totally fine with dropping support to fake seclabels, if LSM
> developers see no need for it. I, certainly, will not insist on it.
> With that in mind, I'd prefer if we limit this discussion to faking CREDS/PIDS.
Well, based on your use case, we actually do need support for faking
seclabels if we need support for faking credentials at all, because your
proxy needs to be able to fake all of the credentials in order to be
fully transparent and preserve compatibility. So I don't think they can
be divorced from each other.
Regardless, we will definitely want a hook for controlling this ability
to fake credentials, and I think we would want to separately distinguish
each of the cases that you currently lump under your single privileged
boolean, as the ability to do one should not necessarily imply the
ability to do them all.
Hi
On Fri, Jul 10, 2015 at 3:25 PM, Stephen Smalley <[email protected]> wrote:
> On 07/09/2015 06:22 PM, David Herrmann wrote:
>> 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?
We need binary compatibility to dbus1. There're millions of
applications and language bindings with dbus1 compiled in, which we
cannot suddenly break.
>> 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?
Each message carries metadata of the sender, that was collected at the
time of _SEND_. This metadata cannot be faked.
Additionally (for introspection and dbus1 compat), kdbus allows peers
to query metadata of other peers, that were collected at the time of
_CONNECT_. Privileged peers can provide faked _connection_ metadata,
which has the side-effect of suppressing send-time metadata.
It is up to the receiver to request connection-metadata if a message
did not carry send-time metadata. We do this, currently, only to
support legacy dbus1 clients which do not support send-time metadata.
>> 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?
Regarding the default security model (uid based), each bus is prefixed
by the uid of the bus-owner. This is enforced by the kernel. Hence, a
process cannot 'accidentally' connect to a bus of a user they don't
trust.
Thanks
David
Am Freitag, 10. Juli 2015, 15:43:08 schrieb David Herrmann:
> Hi
Hi,
> On Fri, Jul 10, 2015 at 3:25 PM, Stephen Smalley <[email protected]>
> wrote:
> > On 07/09/2015 06:22 PM, David Herrmann wrote:
> >> 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?
>
> We need binary compatibility to dbus1. There're millions of
> applications and language bindings with dbus1 compiled in, which we
> cannot suddenly break.
Wow, do I get this right, that this credential faking – I do think that the
last two words are already completely sufficient to show the insanity of it
at least when I apply something to it that is commonly called common sense,
credential *what*? – is just for supporting something that is broken in
userspace already?
I do get the "never break userspace" mantra for anything *already*
implemented in the kernel. But this is more like "userspace is broken, lets
port it into the kernel and keep the brokenness while doing so thus setting
the brokenness in stone" due to the first mantra.
I did not look at the actual code, but from the mere reading of this, I
shudder.
I am happy that you digged this out of the larger thread with a descriptive
thread title, so that this may get some attention, Stephen.
Ciao,
--
Martin
Am Freitag, 10. Juli 2015, 16:20:44 schrieb Martin Steigerwald:
> Am Freitag, 10. Juli 2015, 15:43:08 schrieb David Herrmann:
> > Hi
>
> Hi,
>
> > On Fri, Jul 10, 2015 at 3:25 PM, Stephen Smalley <[email protected]>
> >
> > wrote:
> > > On 07/09/2015 06:22 PM, David Herrmann wrote:
> > >> 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?
> >
> >
> >
> > We need binary compatibility to dbus1. There're millions of
> > applications and language bindings with dbus1 compiled in, which we
> > cannot suddenly break.
>
> Wow, do I get this right, that this credential faking – I do think that
> the last two words are already completely sufficient to show the
> insanity of it at least when I apply something to it that is commonly
> called common sense, credential *what*? – is just for supporting
> something that is broken in userspace already?
Ok, I think I now get the dbus-1 userspace probably didn´t need credential
faking to provide this functionality of providing seclabels to dbus clients.
So it is more:
"ok, we have some userspace functionality that we need to be compatible to
it, but in order to do this, we need to do something in the kernel that is
broken by design"
I vote for keeping the functionality inside userspace then.
--
Martin
On 07/10/2015 09:43 AM, David Herrmann wrote:
> Hi
>
> On Fri, Jul 10, 2015 at 3:25 PM, Stephen Smalley <[email protected]> wrote:
>> On 07/09/2015 06:22 PM, David Herrmann wrote:
>>> 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?
>
> We need binary compatibility to dbus1. There're millions of
> applications and language bindings with dbus1 compiled in, which we
> cannot suddenly break.
So, are you saying that there are many applications that statically link
the dbus1 library implementation (thus the distributions can't just push
an updated shared library that switches from using the socket to using
kdbus), and that many of these applications are third party applications
not packaged by the distributions (thus the distributions cannot just do
a mass rebuild to update these applications too)? Otherwise, I would
think that the use of a socket would just be an implementation detail
and you would be free to change it without affecting dbus1 library ABI
compatibility.
>>> 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?
>
> Each message carries metadata of the sender, that was collected at the
> time of _SEND_. This metadata cannot be faked.
> Additionally (for introspection and dbus1 compat), kdbus allows peers
> to query metadata of other peers, that were collected at the time of
> _CONNECT_. Privileged peers can provide faked _connection_ metadata,
> which has the side-effect of suppressing send-time metadata.
> It is up to the receiver to request connection-metadata if a message
> did not carry send-time metadata. We do this, currently, only to
> support legacy dbus1 clients which do not support send-time metadata.
So the "privileged" peer (which just means the bus owner, which can be
completely unprivileged from a typical DAC perspective) can both prevent
the receiver from getting the (real, unfakeable) send-time metadata and
supply arbitrary fake credentials for the connection metadata? And the
legacy dbus1 clients (i.e. all current DBUS applications?) will always
use this potentially faked metadata. Meanwhile, what about new dbus
clients? What is the standard behavior for them when the send-time
metadata is suppressed? Do they always fall back to the connection
metadata?
>>> 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?
>
> Regarding the default security model (uid based), each bus is prefixed
> by the uid of the bus-owner. This is enforced by the kernel. Hence, a
> process cannot 'accidentally' connect to a bus of a user they don't
> trust.
And how do they go about looking up / obtaining the destination bus name
in the first place? At what point would they in fact do any validation
that the uid prefix of the bus is what they expect?
On 7/10/2015 6:43 AM, David Herrmann wrote:
> Hi
>
> On Fri, Jul 10, 2015 at 3:25 PM, Stephen Smalley <[email protected]> wrote:
>> On 07/09/2015 06:22 PM, David Herrmann wrote:
>>> 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?
> We need binary compatibility to dbus1. There're millions of
> applications and language bindings with dbus1 compiled in, which we
> cannot suddenly break.
Rubbish. That's like saying that systemd has to support starting
services from /etc/rc.d, or that the python runtime has to execute
perl scripts. If kdbus is better (or even just cooler or more popular)
the change over will be swift and painless. The *only* reason that
won't be true is if the benefits of kdbus are unclear, in which case
it shouldn't be adopted.
Also, I serious doubt your "millions" number. You might want to
try getting an credible estimate of the impact before using it as
an argument.
>
>>> 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?
> Each message carries metadata of the sender, that was collected at the
> time of _SEND_. This metadata cannot be faked.
> Additionally (for introspection and dbus1 compat), kdbus allows peers
> to query metadata of other peers, that were collected at the time of
> _CONNECT_. Privileged peers can provide faked _connection_ metadata,
> which has the side-effect of suppressing send-time metadata.
> It is up to the receiver to request connection-metadata if a message
> did not carry send-time metadata. We do this, currently, only to
> support legacy dbus1 clients which do not support send-time metadata.
>
>>> 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?
> Regarding the default security model (uid based), each bus is prefixed
> by the uid of the bus-owner. This is enforced by the kernel. Hence, a
> process cannot 'accidentally' connect to a bus of a user they don't
> trust.
Wow. Are you really convinced by that argument? It's like saying that
you know what service is active on a port because you looked in
/etc/services. There are so many ways uids are being (miss/ab)used
on Linux systems these days that the idea of trusting a bus just
because its non-root uid is listed in a table somewhere (or worse,
coded in an API) is asking for exploits.
>
> Thanks
> David
>
Hi
On Fri, Jul 10, 2015 at 5:59 PM, Casey Schaufler <[email protected]> wrote:
[...]
> There are so many ways uids are being (miss/ab)used
> on Linux systems these days that the idea of trusting a bus just
> because its non-root uid is listed in a table somewhere (or worse,
> coded in an API) is asking for exploits.
Please elaborate on these possible exploits. I'd also like to hear,
whether the same applies to the already used '/run/user/<uid>/bus',
which follows nearly the same model.
Thanks
David
Hi
On Fri, Jul 10, 2015 at 4:47 PM, Stephen Smalley <[email protected]> wrote:
> On 07/10/2015 09:43 AM, David Herrmann wrote:
>> On Fri, Jul 10, 2015 at 3:25 PM, Stephen Smalley <[email protected]> wrote:
>>> On 07/09/2015 06:22 PM, David Herrmann wrote:
>>>> 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?
>>
>> Each message carries metadata of the sender, that was collected at the
>> time of _SEND_. This metadata cannot be faked.
>> Additionally (for introspection and dbus1 compat), kdbus allows peers
>> to query metadata of other peers, that were collected at the time of
>> _CONNECT_. Privileged peers can provide faked _connection_ metadata,
>> which has the side-effect of suppressing send-time metadata.
>> It is up to the receiver to request connection-metadata if a message
>> did not carry send-time metadata. We do this, currently, only to
>> support legacy dbus1 clients which do not support send-time metadata.
>
> So the "privileged" peer (which just means the bus owner, which can be
> completely unprivileged from a typical DAC perspective) can both prevent
> the receiver from getting the (real, unfakeable) send-time metadata and
> supply arbitrary fake credentials for the connection metadata? And the
(Limited to PIDS/CREDS/SECLABEL metadata, but) yes.
Note that this is all under the assumption that you never connect to a
bus owned by someone else but you or root. Hence, a peer can only fake
metadata, if it can also ptrace you.
> legacy dbus1 clients (i.e. all current DBUS applications?) will always
> use this potentially faked metadata. Meanwhile, what about new dbus
> clients? What is the standard behavior for them when the send-time
> metadata is suppressed? Do they always fall back to the connection
> metadata?
This is a decision user-space has to make. In sd-bus, if we trust the
bus (root owned, or our own), we always fall back to connection
metadata.
>>>> 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?
>>
>> Regarding the default security model (uid based), each bus is prefixed
>> by the uid of the bus-owner. This is enforced by the kernel. Hence, a
>> process cannot 'accidentally' connect to a bus of a user they don't
>> trust.
>
> And how do they go about looking up / obtaining the destination bus name
> in the first place? At what point would they in fact do any validation
> that the uid prefix of the bus is what they expect?
To connect to your user-bus, you open:
/sys/fs/kdbus/1000-user/bus
(replacing '1000' by getuid(2))
To connect to the system-bus, you open:
/sys/fs/kdbus/0-system/bus
In both cases, you trust the uid, as it's either root or yourself.
Exact same logic applies if you open the dbus1 unix-sockets. You
simply open /run/user/1000/bus (or /run/dbus/system_bus_socket).
I don't see a reason why you'd ever connect to a bus of another user.
If you want to talk to another user, you should use a channel both of
you trust, that is, a system bus.
Thanks
David
On 7/10/2015 9:26 AM, David Herrmann wrote:
> Hi
>
> On Fri, Jul 10, 2015 at 5:59 PM, Casey Schaufler <[email protected]> wrote:
> [...]
>> There are so many ways uids are being (miss/ab)used
>> on Linux systems these days that the idea of trusting a bus just
>> because its non-root uid is listed in a table somewhere (or worse,
>> coded in an API) is asking for exploits.
> Please elaborate on these possible exploits. I'd also like to hear,
> whether the same applies to the already used '/run/user/<uid>/bus',
> which follows nearly the same model.
Sorry, I'm not the exploit generator guy. If I where, I would
point out that the application expecting the uid to identify
a person is going to behave incorrectly on the system that uses
the uid to identify an application. I never said that I liked
/run/user/<uid>/bus. Come to think of it, I never said I like
dbus, either.
>
> Thanks
> David
>
On Fri, Jul 10, 2015 at 7:16 PM, Casey Schaufler <[email protected]> wrote:
> On 7/10/2015 9:26 AM, David Herrmann wrote:
>> Hi
>>
>> On Fri, Jul 10, 2015 at 5:59 PM, Casey Schaufler <[email protected]> wrote:
>> [...]
>>> There are so many ways uids are being (miss/ab)used
>>> on Linux systems these days that the idea of trusting a bus just
>>> because its non-root uid is listed in a table somewhere (or worse,
>>> coded in an API) is asking for exploits.
>> Please elaborate on these possible exploits. I'd also like to hear,
>> whether the same applies to the already used '/run/user/<uid>/bus',
>> which follows nearly the same model.
>
> Sorry, I'm not the exploit generator guy. If I where, I would
> point out that the application expecting the uid to identify
> a person is going to behave incorrectly on the system that uses
> the uid to identify an application. I never said that I liked
> /run/user/<uid>/bus. Come to think of it, I never said I like
> dbus, either.
What did you mean by uids are being abused or misused?
--
Thanks,
//richard
On 07/10/2015 12:48 PM, David Herrmann wrote:
> Hi
>
> On Fri, Jul 10, 2015 at 4:47 PM, Stephen Smalley <[email protected]> wrote:
>> On 07/10/2015 09:43 AM, David Herrmann wrote:
>>> On Fri, Jul 10, 2015 at 3:25 PM, Stephen Smalley <[email protected]> wrote:
>>>> On 07/09/2015 06:22 PM, David Herrmann wrote:
>>>>> 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?
>>>
>>> Each message carries metadata of the sender, that was collected at the
>>> time of _SEND_. This metadata cannot be faked.
>>> Additionally (for introspection and dbus1 compat), kdbus allows peers
>>> to query metadata of other peers, that were collected at the time of
>>> _CONNECT_. Privileged peers can provide faked _connection_ metadata,
>>> which has the side-effect of suppressing send-time metadata.
>>> It is up to the receiver to request connection-metadata if a message
>>> did not carry send-time metadata. We do this, currently, only to
>>> support legacy dbus1 clients which do not support send-time metadata.
>>
>> So the "privileged" peer (which just means the bus owner, which can be
>> completely unprivileged from a typical DAC perspective) can both prevent
>> the receiver from getting the (real, unfakeable) send-time metadata and
>> supply arbitrary fake credentials for the connection metadata? And the
>
> (Limited to PIDS/CREDS/SECLABEL metadata, but) yes.
>
> Note that this is all under the assumption that you never connect to a
> bus owned by someone else but you or root. Hence, a peer can only fake
> metadata, if it can also ptrace you.
If you don't enforce this assumption in kdbus, then you can't be sure
that it won't be violated by future userspace.
Also, the statement about ptrace doesn't hold when using SELinux or
other security modules.
>> legacy dbus1 clients (i.e. all current DBUS applications?) will always
>> use this potentially faked metadata. Meanwhile, what about new dbus
>> clients? What is the standard behavior for them when the send-time
>> metadata is suppressed? Do they always fall back to the connection
>> metadata?
>
> This is a decision user-space has to make. In sd-bus, if we trust the
> bus (root owned, or our own), we always fall back to connection
> metadata.
So the only benefit of the credentials in the send-time metadata is they
come for free rather than needing to be separately queried? And aside
from credential faking (impersonation being a nicer name), when else
would they differ from the connection metadata? If the program does a
setuid or something after creating the connection?
>>>>> 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?
>>>
>>> Regarding the default security model (uid based), each bus is prefixed
>>> by the uid of the bus-owner. This is enforced by the kernel. Hence, a
>>> process cannot 'accidentally' connect to a bus of a user they don't
>>> trust.
>>
>> And how do they go about looking up / obtaining the destination bus name
>> in the first place? At what point would they in fact do any validation
>> that the uid prefix of the bus is what they expect?
>
> To connect to your user-bus, you open:
> /sys/fs/kdbus/1000-user/bus
> (replacing '1000' by getuid(2))
>
> To connect to the system-bus, you open:
> /sys/fs/kdbus/0-system/bus
>
> In both cases, you trust the uid, as it's either root or yourself.
> Exact same logic applies if you open the dbus1 unix-sockets. You
> simply open /run/user/1000/bus (or /run/dbus/system_bus_socket).
>
> I don't see a reason why you'd ever connect to a bus of another user.
> If you want to talk to another user, you should use a channel both of
> you trust, that is, a system bus.
Ok, I understand your model now at least, although I think you are at
risk of userspace doing unsafe things with it in the future.
For our purposes, I think the conclusion is that we'll have to allow
support for seclabel faking to remain (assuming that your compatibility
argument is valid, which I'm not really in a position to evaluate), but
obviously we'll want to add a hook over that and all of the other
"privileged" operations based on more than just uid or CAP_IPC_OWNER.
Beyond that, I assume the natural places to hook are the
kdbus_conn_policy_*() functions, e.g. kdbus_conn_policy_talk(),
_own_name(), etc.
On 7/10/2015 11:02 AM, Richard Weinberger wrote:
> On Fri, Jul 10, 2015 at 7:16 PM, Casey Schaufler <[email protected]> wrote:
>> On 7/10/2015 9:26 AM, David Herrmann wrote:
>>> Hi
>>>
>>> On Fri, Jul 10, 2015 at 5:59 PM, Casey Schaufler <[email protected]> wrote:
>>> [...]
>>>> There are so many ways uids are being (miss/ab)used
>>>> on Linux systems these days that the idea of trusting a bus just
>>>> because its non-root uid is listed in a table somewhere (or worse,
>>>> coded in an API) is asking for exploits.
>>> Please elaborate on these possible exploits. I'd also like to hear,
>>> whether the same applies to the already used '/run/user/<uid>/bus',
>>> which follows nearly the same model.
>> Sorry, I'm not the exploit generator guy. If I where, I would
>> point out that the application expecting the uid to identify
>> a person is going to behave incorrectly on the system that uses
>> the uid to identify an application. I never said that I liked
>> /run/user/<uid>/bus. Come to think of it, I never said I like
>> dbus, either.
> What did you mean by uids are being abused or misused?
The uid is intended to identify a human on a shared machine.
The traditional Linux access control model assumes that the
various users (identified by uid) are aware of what they are
doing and sharing information in the way they intend. Further,
they are responsible for the behavior of the programs that
they run.
On some systems the uid is being used as an application identifier
instead of a human identifier. The access controls are not designed
for this. The POSIX capabilities aren't designed for this. If Fred
creates a program that is setuid to fred and gets Barney to run it,
you hold Fred accountable. If a malicious (or compromised) application
identified by "fred" creates a setuid fred program and the "barney"
application runs it, who do you hold accountable? It's a completely
different mindset. Sure, you can wedge the one into the other, but
it's not the intended use. Hence, misuse or abuse.
I understand the temptation to repurpose the uid on a single user
platform. It's easy to explain and works at the slideware level.
It's a whole lot easier than creating a security module to do the
job correctly, although there's work underway to address that issue.
Am 10.07.2015 um 20:36 schrieb Casey Schaufler:
> On 7/10/2015 11:02 AM, Richard Weinberger wrote:
>> On Fri, Jul 10, 2015 at 7:16 PM, Casey Schaufler <[email protected]> wrote:
>>> On 7/10/2015 9:26 AM, David Herrmann wrote:
>>>> Hi
>>>>
>>>> On Fri, Jul 10, 2015 at 5:59 PM, Casey Schaufler <[email protected]> wrote:
>>>> [...]
>>>>> There are so many ways uids are being (miss/ab)used
>>>>> on Linux systems these days that the idea of trusting a bus just
>>>>> because its non-root uid is listed in a table somewhere (or worse,
>>>>> coded in an API) is asking for exploits.
>>>> Please elaborate on these possible exploits. I'd also like to hear,
>>>> whether the same applies to the already used '/run/user/<uid>/bus',
>>>> which follows nearly the same model.
>>> Sorry, I'm not the exploit generator guy. If I where, I would
>>> point out that the application expecting the uid to identify
>>> a person is going to behave incorrectly on the system that uses
>>> the uid to identify an application. I never said that I liked
>>> /run/user/<uid>/bus. Come to think of it, I never said I like
>>> dbus, either.
>> What did you mean by uids are being abused or misused?
>
> The uid is intended to identify a human on a shared machine.
> The traditional Linux access control model assumes that the
> various users (identified by uid) are aware of what they are
> doing and sharing information in the way they intend. Further,
> they are responsible for the behavior of the programs that
> they run.
>
> On some systems the uid is being used as an application identifier
> instead of a human identifier. The access controls are not designed
> for this. The POSIX capabilities aren't designed for this. If Fred
> creates a program that is setuid to fred and gets Barney to run it,
> you hold Fred accountable. If a malicious (or compromised) application
> identified by "fred" creates a setuid fred program and the "barney"
> application runs it, who do you hold accountable? It's a completely
> different mindset. Sure, you can wedge the one into the other, but
> it's not the intended use. Hence, misuse or abuse.
>
> I understand the temptation to repurpose the uid on a single user
> platform. It's easy to explain and works at the slideware level.
> It's a whole lot easier than creating a security module to do the
> job correctly, although there's work underway to address that issue.
Thanks a lot for pointing this out.
Things are much clearer now. :)
Thanks,
//richard
On Fri, Jul 10, 2015 at 10:47:32AM -0400, Stephen Smalley wrote:
> On 07/10/2015 09:43 AM, David Herrmann wrote:
> > Hi
> >
> > On Fri, Jul 10, 2015 at 3:25 PM, Stephen Smalley <[email protected]> wrote:
> >> On 07/09/2015 06:22 PM, David Herrmann wrote:
> >>> 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?
> >
> > We need binary compatibility to dbus1. There're millions of
> > applications and language bindings with dbus1 compiled in, which we
> > cannot suddenly break.
>
> So, are you saying that there are many applications that statically link
> the dbus1 library implementation (thus the distributions can't just push
> an updated shared library that switches from using the socket to using
> kdbus), and that many of these applications are third party applications
> not packaged by the distributions (thus the distributions cannot just do
> a mass rebuild to update these applications too)?
Yes.
There are also programs that use "native" dbus libraries written in
other languages than C that use the unix-socket to talk the dbus
protocol to the system. As a specific example, Go has one of these
libraries, and it's built statically into go binaries, so there is no
"system library" that could be updated for these binaries to avoid this
interface.
I'm sure over time that these libraries will move toward using kdbus
"directly" if it is present, but at the moment, we don't have that
luxury.
> Otherwise, I would think that the use of a socket would just be an
> implementation detail and you would be free to change it without
> affecting dbus1 library ABI compatibility.
I wish we could, but we can't break programs that are currently running
today, that would be pretty mean.
thanks,
greg k-h
On Fri, Jul 10, 2015 at 03:43:08PM +0200, David Herrmann wrote:
> We need binary compatibility to dbus1. There're millions of
> applications and language bindings with dbus1 compiled in, which we
> cannot suddenly break.
But they can keep using the existing userspace dbus1, and move over
to an in-kernel dbus2 after being audited/ported.
This whole argumet of we did something stupid in userspace long ago, and
now need to move it to kernelspace is not very helpful.
On Fri, Jul 10, 2015 at 8:36 PM, Casey Schaufler <[email protected]> wrote:
> On some systems the uid is being used as an application identifier
> instead of a human identifier. The access controls are not designed
> for this. The POSIX capabilities aren't designed for this. If Fred
> creates a program that is setuid to fred and gets Barney to run it,
> you hold Fred accountable. If a malicious (or compromised) application
> identified by "fred" creates a setuid fred program and the "barney"
> application runs it, who do you hold accountable? It's a completely
> different mindset. Sure, you can wedge the one into the other, but
> it's not the intended use. Hence, misuse or abuse.
Actually that's an interesting thought.
The question is whether the /run/user/<uid>/bus security model works
also for "special" userland like Android.
To my knowledge on Android each application runs as different user.
If kdbus gets merged it would be nice to have to work with all kinds of userland
and not only Fedora.
--
Thanks,
//richard