Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S933118AbbGJSgV (ORCPT <rfc822;w@1wt.eu>);
	Fri, 10 Jul 2015 14:36:21 -0400
Received: from smtp106.biz.mail.bf1.yahoo.com ([98.139.244.54]:44780 "EHLO
	smtp106.biz.mail.bf1.yahoo.com" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S932724AbbGJSgL (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 10 Jul 2015 14:36:11 -0400
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: WoBFvAEVM1ld_.dzo1hxhj70RQlnxqb7f51bqWFTbChljTS
 K0.XUiYkuzcNDtsLLS1ONhx_mQ1FOAvvenSaX08iHDpsnYuz6_rzT8hm507F
 dskQkuKP4RyNqMMhE.CNMZFatDDXok_lEIs7y0nxuIcCE3QPhB49vU1MPW9k
 fWfD9evO1ROOFRoNKhjDhGsnIFlCqP8baDS1i6KfuzbYq.0N5Pf8WHUn1jhd
 TkQhQxfPifV6LLO6vJft_pCHRcQ_jYMEbSvGut9hnky9oTWiccKuDwDdXQgI
 1VFPCxzhZhA5eLqPlwgHaQzdf8t9DkunucON9cKy5q8VYLRUsfe1ty.sIm4I
 GEy4NtURW4E4q7HHj4cIqBFrugdq00V7BeFGsi.whu3kDwmNyh_ZOY8CqL6m
 AH25.w_OJ.f4RbN13WJYCNqzcpkeEAuhHZdRjwyvQEonzntKP29dE262Y2rM
 Zct9hjKT3DMqPrJR_D4xnCAbiWfFp5xk0a15WfpF6JOcOAMKafyYtfwUsO_Y
 LDNTdwssroxlswTazWvMcOVVQHM_dC9Af1GgCLerzsdpi4IXULlFQqYTZg6U
 -
X-Yahoo-SMTP: OIJXglSswBDfgLtXluJ6wiAYv6_cnw--
Message-ID: <55A01099.4030708@schaufler-ca.com>
Date: Fri, 10 Jul 2015 11:36:09 -0700
From: Casey Schaufler <casey@schaufler-ca.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Richard Weinberger <richard.weinberger@gmail.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>
In-Reply-To: <CAFLxGvxxDvobrtWm4YiDwMtX7A5EH7crtyE+gi5UNmZqkJ6YZQ@mail.gmail.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: 2555
Lines: 49

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.

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