From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S967170AbcA1Ag2 (ORCPT ); Wed, 27 Jan 2016 19:36:28 -0500 Received: from mail-ob0-f177.google.com ([209.85.214.177]:33601 "EHLO mail-ob0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S967100AbcA1AgX (ORCPT ); Wed, 27 Jan 2016 19:36:23 -0500 MIME-Version: 1.0 In-Reply-To: <20160127172225.GA7967@pc.thejh.net> References: <20151130224356.GA27972@mail.hallyn.com> <87two3w0el.fsf@x220.int.ebiederm.org> <20151204202116.GA4809@mail.hallyn.com> <20160120124816.GB32379@pc.thejh.net> <20160127160815.GA28787@mail.hallyn.com> <20160127172225.GA7967@pc.thejh.net> From: Andy Lutomirski Date: Wed, 27 Jan 2016 16:36:02 -0800 Message-ID: Subject: Re: [PATCH RFC] Introduce new security.nscapability xattr To: Jann Horn Cc: "Serge E. Hallyn" , "Eric W. Biederman" , "Serge E. Hallyn" , lkml , Andrew Morgan , LXC development mailing-list , Richard Weinberger , LSM , Linux API , Kees Cook Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 27, 2016 at 9:22 AM, Jann Horn wrote: > I think it sounds good from a security perspective. I'm a bit late to the game, but I have a question: why should this be keyed to the *root* uid of the namespace in particular? Certainly if user foo trusts the cap bits on some file, then user foo might trust those caps to be exerted over any namespace that user foo owns, since user foo owns the namespace. But another option would be to include a list of uids and gids such that the cap bits on the file are trusted by any namespace that maps only uids and gids in the list. After all, the existence of a namespace with root user foo that also maps bar and baz along with a file with caps set means that, if baz can get to the file and permissions are set appropriately, then baz now owns bar (via any number of fs-related capabilities). So maybe bar and baz should have to be listed as well. But maybe this doesn't matter. In any event, at the end of the day, the right answer to all of this is to stop using setuid and stop using cap bits too and start using privileged daemons or other things that don't use the eternally fragile grant-privilege-on-execve mechanisms. --Andy From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Subject: Re: [PATCH RFC] Introduce new security.nscapability xattr Date: Wed, 27 Jan 2016 16:36:02 -0800 Message-ID: References: <20151130224356.GA27972@mail.hallyn.com> <87two3w0el.fsf@x220.int.ebiederm.org> <20151204202116.GA4809@mail.hallyn.com> <20160120124816.GB32379@pc.thejh.net> <20160127160815.GA28787@mail.hallyn.com> <20160127172225.GA7967@pc.thejh.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <20160127172225.GA7967-J1fxOzX/cBvk1uMJSBkQmQ@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Jann Horn Cc: "Serge E. Hallyn" , "Eric W. Biederman" , "Serge E. Hallyn" , lkml , Andrew Morgan , LXC development mailing-list , Richard Weinberger , LSM , Linux API , Kees Cook List-Id: linux-api@vger.kernel.org On Wed, Jan 27, 2016 at 9:22 AM, Jann Horn wrote: > I think it sounds good from a security perspective. I'm a bit late to the game, but I have a question: why should this be keyed to the *root* uid of the namespace in particular? Certainly if user foo trusts the cap bits on some file, then user foo might trust those caps to be exerted over any namespace that user foo owns, since user foo owns the namespace. But another option would be to include a list of uids and gids such that the cap bits on the file are trusted by any namespace that maps only uids and gids in the list. After all, the existence of a namespace with root user foo that also maps bar and baz along with a file with caps set means that, if baz can get to the file and permissions are set appropriately, then baz now owns bar (via any number of fs-related capabilities). So maybe bar and baz should have to be listed as well. But maybe this doesn't matter. In any event, at the end of the day, the right answer to all of this is to stop using setuid and stop using cap bits too and start using privileged daemons or other things that don't use the eternally fragile grant-privilege-on-execve mechanisms. --Andy