Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932264AbbGJNcg (ORCPT ); Fri, 10 Jul 2015 09:32:36 -0400 Received: from emvm-gh1-uea08.nsa.gov ([63.239.67.9]:55339 "EHLO emvm-gh1-uea08.nsa.gov" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751607AbbGJNc2 (ORCPT ); Fri, 10 Jul 2015 09:32:28 -0400 X-TM-IMSS-Message-ID: <898e453c001126df@nsa.gov> Message-ID: <559FC8C2.6030409@tycho.nsa.gov> Date: Fri, 10 Jul 2015 09:29:38 -0400 From: Stephen Smalley Organization: National Security Agency User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: David Herrmann , Casey Schaufler CC: Greg KH , Daniel Mack , Djalal Harouni , lkml , LSM , Paul Osmialowski , Paul Moore Subject: Re: kdbus: credential faking References: <559EBCC0.7040604@tycho.nsa.gov> <559EFC24.5050705@schaufler-ca.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2348 Lines: 50 On 07/10/2015 05:05 AM, David Herrmann wrote: > Hi > > On Fri, Jul 10, 2015 at 12:56 AM, Casey Schaufler > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/