Re: Issues with capability bits and meta-data in kdbus

[Andy Lutomirski]

On Tue, Apr 21, 2015 at 6:30 PM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Tue, Apr 21, 2015 at 2:06 PM, Eric W. Biederman
> <ebiederm@xxxxxxxxxxxx> wrote:
>> - Access to the capability bits is guarded with PTRACE_MAY_READ
>>   kdbus does not honor that and thus leaks information.
>
> Now, this is likely not a real problem.
>
> Yes, when you try to read other processes capabilities, you need
> PTRACE_MAY_READ to see them. HOWEVER, that's not really what a kdbus
> message would do - it doesn't "read somebody elses capabilities". When
> you do a kdbus write, you export your *own* capabilities. If you don't
> want others to know what privileges you have, then you shouldn't be
> using kdbus.
>
> It's like saying "you need PTRACE_MAY_READ" to be able to read the
> process image of another process. True. But if that other process does
> a "write()" system call, then the written data will contain the data
> from that process. That's how write works.

There's an interesting philosophical question here.

If kdbus were a general purpose IPC tool and if the libraries would
expose nice knobs like "set this flag if and only if you want to
assert CAP_WHATEVER to the server", then maybe this would be okay.

But I don't believe that for a second.  AFAICS sd-bus (maybe the
primary implementation) will always set that flag if for no other
reason than that it *doesn't know* when the client is trying to assert
a capability.  So we'd be giving users a gun which is, in practice,
only ever pointed at the users' feet.

It's a little worse than that, since this gun also shoots
cap_permitted, cap_inheritable, and bset bullets, none of which seem
usable for anything other than foot-shooting even in the best case.
And don't even get me started about some of the other metadata items.

All of this completely ignores the fact that selinux can and does
restrict access to /proc and kdbus will never respect those
restrictions.  Also, I'd like to see us move closer to a world where
real distros set hide_pid=1, and this is a big step in the opposite
direction.

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