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: <559FC8C2.6030409@tycho.nsa.gov>
Date:	Fri, 10 Jul 2015 09:29:38 -0400
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	David Herrmann <dh.herrmann@...il.com>,
	Casey Schaufler <casey@...aufler-ca.com>
CC:	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

On 07/10/2015 05:05 AM, David Herrmann wrote:
> Hi
> 
> On Fri, Jul 10, 2015 at 12:56 AM, Casey Schaufler
> <casey@...aufler-ca.com> wrote:
>> On 7/9/2015 3:22 PM, David Herrmann wrote:
>>> Regarding requiring CAP_SYS_ADMIN, I don't really see the point. In
>>> the kdbus security model, if you don't trust the bus-creator, you
>>> should not connect to the bus.
>>
>> That's fine in a discretionary access control model, but
>> not in a mandatory access control model. The decision on
>> trust of the "other" guy is never up to the process, it's
>> up to the mandatory access control policy.
> 
> Exactly. So LSMs are free to use a hook to limit faking other user's
> credentials. But why does that have to affect the default (which, in
> the case of kdbus, is a dac model)?
> 
>>> A bus-creator can bypass kdbus
>>> policies, sniff on any transmission and modify bus behavior. It just
>>> seems logical to bind faked-metadata to the same privilege. However, I
>>> also have no strong feeling about that, if you place valid points. So
>>> please elaborate.
>>
>> Smack has to require CAP_MAC_ADMIN to allow a process to fake
>> Smack metadata. This is exactly what CAP_MAC_ADMIN is for.
>> Changing Smack metadata is considered a hugely dangerous activity.
> 
> I'm totally fine with dropping support to fake seclabels, if LSM
> developers see no need for it. I, certainly, will not insist on it.
> With that in mind, I'd prefer if we limit this discussion to faking CREDS/PIDS.

Well, based on your use case, we actually do need support for faking
seclabels if we need support for faking credentials at all, because your
proxy needs to be able to fake all of the credentials in order to be
fully transparent and preserve compatibility.  So I don't think they can
be divorced from each other.

Regardless, we will definitely want a hook for controlling this ability
to fake credentials, and I think we would want to separately distinguish
each of the cases that you currently lump under your single privileged
boolean, as the ability to do one should not necessarily imply the
ability to do them all.

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