Re: kdbus: credential faking

[Casey Schaufler]

On 7/10/2015 11:02 AM, Richard Weinberger wrote:
> On Fri, Jul 10, 2015 at 7:16 PM, Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote:
>> On 7/10/2015 9:26 AM, David Herrmann wrote:
>>> Hi
>>>
>>> On Fri, Jul 10, 2015 at 5:59 PM, Casey Schaufler <casey@xxxxxxxxxxxxxxxx> 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.

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