Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S933313AbbGJSjP (ORCPT <rfc822;w@1wt.eu>);
	Fri, 10 Jul 2015 14:39:15 -0400
Received: from a.ns.miles-group.at ([95.130.255.143]:65276 "EHLO radon.swed.at"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S932941AbbGJSjL (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Fri, 10 Jul 2015 14:39:11 -0400
Message-ID: <55A0114A.6030100@nod.at>
Date: Fri, 10 Jul 2015 20:39:06 +0200
From: Richard Weinberger <richard@nod.at>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Casey Schaufler <casey@schaufler-ca.com>
CC: David Herrmann <dh.herrmann@gmail.com>,
        Stephen Smalley <sds@tycho.nsa.gov>,
        Greg KH <gregkh@linuxfoundation.org>, Daniel Mack <daniel@zonque.org>,
        Djalal Harouni <tixxdz@opendz.org>,
        lkml <linux-kernel@vger.kernel.org>,
        LSM <linux-security-module@vger.kernel.org>,
        Paul Osmialowski <p.osmialowsk@samsung.com>,
        Paul Moore <paul@paul-moore.com>
Subject: Re: kdbus: credential faking
References: <559EBCC0.7040604@tycho.nsa.gov>	<CANq1E4QH37+H3cbauN8LDRxp+Rsmtcn6CkLYCiV7XQrhm=qP9Q@mail.gmail.com>	<559FC7DD.8060507@tycho.nsa.gov>	<CANq1E4TaE6EK1iEGLq_Zhu6=z52VZx7sPFc4TVc1vt1F3pShcA@mail.gmail.com>	<559FEBF2.1040908@schaufler-ca.com>	<CANq1E4Sdpb81PW9Ju+bnRjtZ=9HkGwGse-gstx1SjaEzmWiT-w@mail.gmail.com>	<559FFDDF.2090302@schaufler-ca.com> <CAFLxGvxxDvobrtWm4YiDwMtX7A5EH7crtyE+gi5UNmZqkJ6YZQ@mail.gmail.com> <55A01099.4030708@schaufler-ca.com>
In-Reply-To: <55A01099.4030708@schaufler-ca.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2759
Lines: 58

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@schaufler-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@schaufler-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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/