Re: kdbus: credential faking

[David Herrmann]

Hi

On Fri, Jul 10, 2015 at 12:56 AM, Casey Schaufler
<casey@xxxxxxxxxxxxxxxx> 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
--
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/