linux-kernel - Re: kdbus: credential faking

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <55A0114A.6030100@nod.at>
Date:	Fri, 10 Jul 2015 20:39:06 +0200
From:	Richard Weinberger <richard@....at>
To:	Casey Schaufler <casey@...aufler-ca.com>
CC:	David Herrmann <dh.herrmann@...il.com>,
	Stephen Smalley <sds@...ho.nsa.gov>,
	Greg KH <gregkh@...uxfoundation.org>,
	Daniel Mack <daniel@...que.org>,
	Djalal Harouni <tixxdz@...ndz.org>,
	lkml <linux-kernel@...r.kernel.org>,
	LSM <linux-security-module@...r.kernel.org>,
	Paul Osmialowski <p.osmialowsk@...sung.com>,
	Paul Moore <paul@...l-moore.com>
Subject: Re: kdbus: credential faking

Am 10.07.2015 um 20:36 schrieb Casey Schaufler:
> On 7/10/2015 11:02 AM, Richard Weinberger wrote:
>> On Fri, Jul 10, 2015 at 7:16 PM, Casey Schaufler <casey@...aufler-ca.com> wrote:
>>> On 7/10/2015 9:26 AM, David Herrmann wrote:
>>>> Hi
>>>>
>>>> On Fri, Jul 10, 2015 at 5:59 PM, Casey Schaufler <casey@...aufler-ca.com> 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.

Thanks a lot for pointing this out.
Things are much clearer now. :)

Thanks,
//richard



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/