On 7/10/2015 11:02 AM, Richard Weinberger wrote: > On Fri, Jul 10, 2015 at 7:16 PM, Casey Schaufler <[email protected]> > wrote: >> On 7/10/2015 9:26 AM, David Herrmann wrote: >>> Hi >>> >>> On Fri, Jul 10, 2015 at 5:59 PM, Casey Schaufler <[email protected]> >>> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
