Re: Sharing credentials in general (Re: [GIT PULL] kdbus for 4.1-rc1)

[David Herrmann]

Hi

On Mon, Apr 27, 2015 at 6:13 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
>>>> from the client that accesses a service. The client asks a service
>>>> provider to perform an action. The service provider then asks the
>>>> authorization-framework, whether the client is authorized to run the
>>>> action.
>>>
>>> This is not good design IMHO. The client should always be indicating it
>>> intends to pass on the credentials it has. That stops privileges leaking
>>> or programs being tricked into things.
>>
>> If all you pass along is your identity, you cannot "leak a privilege".
>> If you run a program as someone privileged and you don't want the
>> program to run as such a user, well, then you better not run it as
>> such a user..
>>
>> We don't do setuid or setcap. A caller always has full control who to
>> run a program as. Choose that wisely, don't make the program protect
>> itself against the user. On the contrary, if a program is called with
>> elevated privileges, then this is an explicit decision of the caller
>> we must respect.
>
> Who is "you"?  In the future universe where kdbus takes over as the
> main way of doing privileged things, people most certainly will run
> kdbus clients setuid or setcapped.

They're free to do that. But they need to deal with the consequences.
We encourage people not to do that.

>>>> Without LSM, we don't have such a unique identifier. Therefore, we
>>>> send the UIDs+GIDs+CAPs+NAMEs combination. Those we pass on to the
>>>> authorization framework, to decide on whether the peer is privileged.
>>>> And we believe those should be mandatory, not optional, just like the
>>>> seclabel we send if an LSM is active.
>>>
>>> The mashed up caps and names really ought to be replaced by something
>>> better. Especially the names. Would it make sense to put some kind of
>>> security label on the executable and pass that instead ? So instead of
>>> all the caps and names crap you label the executable itself as having
>>> "kbus:awesomerebootpower" or whatever so the kernel can see that cleanly
>>> as a label that's basically a kbus namespace capability ?
>>
>> (it would be lovely if you did not call my code 'crap')
>>
>> But this is the essential difference in our design. We don't want code
>> to be aware of their privileges. We want privileges to be attached
>> externally to an identity. Thus, a program should always assume it is
>> privileged to do whatever its purpose is. If its purpose does not fit
>> you, you better not call it. In all other cases, a "privilege leak"
>> would just result in the program running as expected.
>>
>
> Two answers:
>
> 1. This is severely inconsistent with other things I've heard recently
> from the kdbus camp.  Lennart wants clients to use caps and adjust
> them.  This would involve those clients being very much aware of their
> privileges, and their privileges would not "be attached externally to
> an identity".  Please make sure you actually understand your security
> model before you try to justify it.

Granting an application a capability is not equivalent to the
application being aware of that capability. In fact, I'd assert the
application doesn't care at all whether it gains the privilege due to
a capability or polkit. It's not hard-coded in the application, but
the unit/polkit configurations.
Exception obviously being if we directly access syscalls.

> 2.  This is a nice thought, but it doesn't work in practice.  Sorry.
> I can give you a big pile of CVEs from last year if you like, or I can
> try explaining again.
>
> The issue boils down to what type of privileges you want to assert and
> over what object you want to assert them.  Suppose I have a method
> "write".  When I call it, I do Write(destination, text).  In your
> model, it's basically never safe to do:

You're correct. So don't create such APIs.
In fact, never ever accept FDs or file-paths from a less privileged
caller. It might be FUSE backed and under their full control.

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