Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754223AbbGJJFw (ORCPT ); Fri, 10 Jul 2015 05:05:52 -0400 Received: from mail-lb0-f179.google.com ([209.85.217.179]:33136 "EHLO mail-lb0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751838AbbGJJFp (ORCPT ); Fri, 10 Jul 2015 05:05:45 -0400 MIME-Version: 1.0 In-Reply-To: <559EFC24.5050705@schaufler-ca.com> References: <559EBCC0.7040604@tycho.nsa.gov> <559EFC24.5050705@schaufler-ca.com> Date: Fri, 10 Jul 2015 11:05:43 +0200 Message-ID: Subject: Re: kdbus: credential faking From: David Herrmann To: Casey Schaufler Cc: Stephen Smalley , Greg KH , Daniel Mack , Djalal Harouni , lkml , LSM , Paul Osmialowski , Paul Moore Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2147 Lines: 51 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. >> But, please be aware that if we require privileges to fake metadata, >> then you need to have such privileges to provide a dbus1 proxy for >> your native bus on kdbus. In other words, users are able to create >> session/user buses, but they need CAP_SYS_ADMIN to spawn the dbus1 >> proxy. This will have the net-effect of us requiring to run the proxy >> as root (which, I think, is worse than allowing bus-owners to fake >> _connection_ metadata). > > I disagree with you strongly. [...] Ok. Thanks David -- 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/