From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753430AbdKISFj (ORCPT ); Thu, 9 Nov 2017 13:05:39 -0500 Received: from h2.hallyn.com ([78.46.35.8]:51032 "EHLO h2.hallyn.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752549AbdKISFi (ORCPT ); Thu, 9 Nov 2017 13:05:38 -0500 Date: Thu, 9 Nov 2017 12:05:36 -0600 From: "Serge E. Hallyn" To: chris hyser Cc: "Serge E. Hallyn" , Daniel Micay , Mahesh Bandewar =?utf-8?B?KOCkruCkueClh+CktiDgpKzgpILgpKHgpYfgpLXgpL4=?= =?utf-8?B?4KSwKQ==?= , Mahesh Bandewar , LKML , Netdev , Kernel-hardening , Linux API , Kees Cook , "Eric W . Biederman" , Eric Dumazet , David Miller Subject: Re: [kernel-hardening] Re: [PATCH resend 2/2] userns: control capabilities of some user namespaces Message-ID: <20171109180536.GA27994@mail.hallyn.com> References: <20171103004436.40026-1-mahesh@bandewar.net> <20171104235346.GA17170@mail.hallyn.com> <20171106150302.GA26634@mail.hallyn.com> <1510003994.736.0.camel@gmail.com> <20171106221418.GA32543@mail.hallyn.com> <1510020963.736.42.camel@gmail.com> <20171107032310.GA6429@mail.hallyn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting chris hyser (chris.hyser@oracle.com): > On 11/06/2017 10:23 PM, Serge E. Hallyn wrote: > >I think I definately prefer what I mentioned in the email to Boris. > >Basically a "permanent capability bounding set". The normal bounding > >set gets reset to a full set on every new user_ns creation. In this > >proposal, it would instead be set to the calling task's permanent > >capability set, which starts (at boot) full, and which privileged > >tasks can pull capabilities out of. > > Actually, this may solve a similar problem I've been looking at. The > idea was basically at strategic points in the kernel (possibly LSM > hook sites, still evaluating, and probably syscall entry) validate > that a task has not "magically" acquired capabilities that it or > parent specifically said it cannot have and then take some action > like say killing it immediately. Using your terms, basically make > the "permanent capability set" a write-once privilege escalation > defense. To handle the 0-day threat, perhaps make it writable but > only with more "restrictive" values. Would the existing capability bounding set not suffice for that? The 'permanent' bounding set turns out to not be a good fit for the problem being discussed in this thread, but please feel free to start a new thread if you want to discuss your use case. From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Serge E. Hallyn" Subject: Re: [kernel-hardening] Re: [PATCH resend 2/2] userns: control capabilities of some user namespaces Date: Thu, 9 Nov 2017 12:05:36 -0600 Message-ID: <20171109180536.GA27994@mail.hallyn.com> References: <20171103004436.40026-1-mahesh@bandewar.net> <20171104235346.GA17170@mail.hallyn.com> <20171106150302.GA26634@mail.hallyn.com> <1510003994.736.0.camel@gmail.com> <20171106221418.GA32543@mail.hallyn.com> <1510020963.736.42.camel@gmail.com> <20171107032310.GA6429@mail.hallyn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Serge E. Hallyn" , Daniel Micay , Mahesh Bandewar =?utf-8?B?KOCkruCkueClh+CktiDgpKzgpILgpKHgpYfgpLXgpL4=?= =?utf-8?B?4KSwKQ==?= , Mahesh Bandewar , LKML , Netdev , Kernel-hardening , Linux API , Kees Cook , "Eric W . Biederman" , Eric Dumazet , David Miller To: chris hyser Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: netdev.vger.kernel.org Quoting chris hyser (chris.hyser-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org): > On 11/06/2017 10:23 PM, Serge E. Hallyn wrote: > >I think I definately prefer what I mentioned in the email to Boris. > >Basically a "permanent capability bounding set". The normal bounding > >set gets reset to a full set on every new user_ns creation. In this > >proposal, it would instead be set to the calling task's permanent > >capability set, which starts (at boot) full, and which privileged > >tasks can pull capabilities out of. > > Actually, this may solve a similar problem I've been looking at. The > idea was basically at strategic points in the kernel (possibly LSM > hook sites, still evaluating, and probably syscall entry) validate > that a task has not "magically" acquired capabilities that it or > parent specifically said it cannot have and then take some action > like say killing it immediately. Using your terms, basically make > the "permanent capability set" a write-once privilege escalation > defense. To handle the 0-day threat, perhaps make it writable but > only with more "restrictive" values. Would the existing capability bounding set not suffice for that? The 'permanent' bounding set turns out to not be a good fit for the problem being discussed in this thread, but please feel free to start a new thread if you want to discuss your use case.