Date: Tue, 3 May 2016 08:19:34 +1000 (AEST) From: James Morris <jmorris@...ei.org> To: Kees Cook <keescook@...omium.org> cc: Mickaël Salaün <mic@...ikod.net>, linux-security-module <linux-security-module@...r.kernel.org>, Andreas Gruenbacher <agruenba@...hat.com>, Andy Lutomirski <luto@...capital.net>, Andy Lutomirski <luto@...nel.org>, Arnd Bergmann <arnd@...db.de>, Casey Schaufler <casey@...aufler-ca.com>, Daniel Borkmann <daniel@...earbox.net>, David Drysdale <drysdale@...gle.com>, Eric Paris <eparis@...hat.com>, James Morris <james.l.morris@...cle.com>, Jeff Dike <jdike@...toit.com>, Julien Tinnes <jln@...gle.com>, Michael Kerrisk <mtk@...7.org>, Paul Moore <pmoore@...hat.com>, Richard Weinberger <richard@....at>, "Serge E . Hallyn" <serge@...lyn.com>, Stephen Smalley <sds@...ho.nsa.gov>, Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>, Will Drewry <wad@...omium.org>, Linux API <linux-api@...r.kernel.org>, "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com> Subject: Re: [RFC v1 00/17] seccomp-object: From attack surface reduction to sandboxing 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 <jmorris@...ei.org>
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.