From: Casey Schaufler <casey@schaufler-ca.com>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
james.l.morris@oracle.com, jmorris@namei.org,
keescook@chromium.org
Cc: linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org, rusty@rustcorp.com.au
Subject: Re: [PATCH] LSM: ModPin LSM for module loading restrictions
Date: Sat, 02 Nov 2013 12:39:14 -0700 [thread overview]
Message-ID: <527554E2.4080806@schaufler-ca.com> (raw)
In-Reply-To: <201310262251.IFB56202.HSFOOtFMVOFLQJ@I-love.SAKURA.ne.jp>
On 10/26/2013 6:51 AM, Tetsuo Handa wrote:
> Tetsuo Handa wrote:
>> I would send another one which uses only security_file_alloc/free .
> I sent it to James, Casey and Kees on "Fri, 18 Oct 2013 22:56:19 +0900" and
> waiting for your response. How long are we expected to remain vulnerable due to
> lack of multiple concurrent LSM support?
Having just spent a good chunk of the past year on the technical
issues, and having participated in the LSM development process since
its inception, I'd say there's at least a year before the dust settles.
Having a wad of code that works is one thing. Breaking it into chunks
that are both useful and small enough for the community to swallow is
another. Transforming a collection of clever hacks into an infrastructure
is a third. Once that's done we can deal with the naysayers.
Fortunately, we have a wad of code that works. Nobody seems to
think that taking that code as is is a great idea. Nobody has
this as their first priority, either. We're making progress, but
we know we need to be careful. I seriously doubt we'll get more
than one shot at it.
next prev parent reply other threads:[~2013-11-02 19:45 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-20 20:35 [PATCH] LSM: ModPin LSM for module loading restrictions Kees Cook
2013-09-24 1:24 ` James Morris
2013-09-24 1:28 ` James Morris
2013-09-24 1:45 ` Kees Cook
2013-10-03 20:55 ` Kees Cook
2013-10-03 21:31 ` Tetsuo Handa
2013-10-03 21:36 ` Kees Cook
2013-10-23 2:55 ` Lucas De Marchi
2013-10-16 15:18 ` Kees Cook
2013-10-16 20:47 ` Tetsuo Handa
2013-10-16 21:42 ` Casey Schaufler
2013-10-16 22:43 ` Kees Cook
2013-10-17 0:37 ` Tetsuo Handa
2013-10-26 13:51 ` Tetsuo Handa
2013-11-02 19:39 ` Casey Schaufler [this message]
2013-10-18 2:25 ` Casey Schaufler
2013-10-17 8:02 ` James Morris
2013-10-17 11:30 ` Jarkko Sakkinen
2013-10-17 21:00 ` Kees Cook
2013-10-17 17:26 ` Casey Schaufler
2013-10-17 21:09 ` Kees Cook
2013-10-23 0:02 ` James Morris
2013-10-23 1:03 ` Casey Schaufler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=527554E2.4080806@schaufler-ca.com \
--to=casey@schaufler-ca.com \
--cc=james.l.morris@oracle.com \
--cc=jmorris@namei.org \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=rusty@rustcorp.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.