Re: kdbus: credential faking

[Richard Weinberger <richard@nod.at>]

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 <casey@schaufler-ca.com> wrote:
>>> On 7/10/2015 9:26 AM, David Herrmann wrote:
>>>> Hi
>>>>
>>>> On Fri, Jul 10, 2015 at 5:59 PM, Casey Schaufler <casey@schaufler-ca.com> 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