From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Morris Subject: Re: [RFC v1 00/17] seccomp-object: From attack surface reduction to sandboxing Date: Tue, 3 May 2016 08:19:34 +1000 (AEST) Message-ID: References: <1458784008-16277-1-git-send-email-mic@digikod.net> Reply-To: kernel-hardening@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Return-path: List-Post: List-Help: List-Unsubscribe: List-Subscribe: In-Reply-To: To: Kees Cook Cc: =?ISO-8859-15?Q?Micka=EBl_Sala=FCn?= , linux-security-module , Andreas Gruenbacher , Andy Lutomirski , Andy Lutomirski , Arnd Bergmann , Casey Schaufler , Daniel Borkmann , David Drysdale , Eric Paris , James Morris , Jeff Dike , Julien Tinnes , Michael Kerrisk , Paul Moore , Richard Weinberger , "Serge E . Hallyn" , Stephen Smalley , Tetsuo Handa , Will Drewry List-Id: linux-api@vger.kernel.org On Wed, 27 Apr 2016, Kees Cook wrote: > Doing "b" means writing a policy engine. I would expect it to look a > lot like either AppArmor or TOMOYO. TOMOYO has network structure > processing, so probably it would look more like TOMOYO if you wanted > more than just file paths. Maybe a seccomp LSM could share logic from > one of the existing path-based LSMs. Right, and that LSM should probably be AppArmor, which is actually being used and maintained. -- James Morris From mboxrd@z Thu Jan 1 00:00:00 1970 Reply-To: kernel-hardening@lists.openwall.com Date: Tue, 3 May 2016 08:19:34 +1000 (AEST) From: James Morris In-Reply-To: Message-ID: References: <1458784008-16277-1-git-send-email-mic@digikod.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Subject: [kernel-hardening] Re: [RFC v1 00/17] seccomp-object: From attack surface reduction to sandboxing To: Kees Cook Cc: =?ISO-8859-15?Q?Micka=EBl_Sala=FCn?= , linux-security-module , Andreas Gruenbacher , Andy Lutomirski , Andy Lutomirski , Arnd Bergmann , Casey Schaufler , Daniel Borkmann , David Drysdale , Eric Paris , James Morris , Jeff Dike , Julien Tinnes , Michael Kerrisk , Paul Moore , Richard Weinberger , "Serge E . Hallyn" , Stephen Smalley , Tetsuo Handa , Will Drewry , Linux API , "kernel-hardening@lists.openwall.com" List-ID: On Wed, 27 Apr 2016, Kees Cook wrote: > Doing "b" means writing a policy engine. I would expect it to look a > lot like either AppArmor or TOMOYO. TOMOYO has network structure > processing, so probably it would look more like TOMOYO if you wanted > more than just file paths. Maybe a seccomp LSM could share logic from > one of the existing path-based LSMs. Right, and that LSM should probably be AppArmor, which is actually being used and maintained. -- James Morris