Messages in this thread | | | From | Andy Lutomirski <> | Date | Tue, 21 Apr 2015 18:54:13 -0700 | Subject | Re: Issues with capability bits and meta-data in kdbus |
| |
On Tue, Apr 21, 2015 at 6:30 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Tue, Apr 21, 2015 at 2:06 PM, Eric W. Biederman > <ebiederm@xmission.com> 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
| |