[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LRH.2.20.1605030816180.21933@namei.org>
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.
