All of lore.kernel.org
 help / color / mirror / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: Kees Cook <keescook@chromium.org>
Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	James Morris <james.l.morris@oracle.com>,
	James Morris <jmorris@namei.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-security-module <linux-security-module@vger.kernel.org>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: [PATCH] LSM: ModPin LSM for module loading restrictions
Date: Thu, 17 Oct 2013 19:25:58 -0700	[thread overview]
Message-ID: <52609C36.2040809@schaufler-ca.com> (raw)
In-Reply-To: <CAGXu5jLSDynZ_XRZGZ+0uZTgtygO1n8+3rOnR+WonH5-tkui6A@mail.gmail.com>

On 10/16/2013 3:43 PM, Kees Cook wrote:
> On Wed, Oct 16, 2013 at 2:42 PM, Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 10/16/2013 1:47 PM, Tetsuo Handa wrote:
>>> Kees Cook wrote:
>>>> Any update on this? It'd be nice to have it in linux-next.
>>> What was the conclusion at LSS about multiple concurrent LSM support?
>>> If we agreed to merge multiple concurrent LSM support, there will be nothing to
>>> prevent this module from merging.
>>>
>> Yeah.
> The discussion at LSS basically centered around the catch-22 of not
> being able to stack, and not having anything to stack (since Yama got
> an hard-coded exception). So I sent this LSM as one I'd been waiting
> for stacking on. Essentially, I'm breaking the catch-22 by sending
> this. I'd like it to get into the tree so we don't have a catch-22
> about stacking any more. :)
>
>> The conclusion was that it needs to be staged because it's
>> too much to swallow all at once. I can see that. It's going
>> to be a lot of work to rearrange and rebase. That's a chunk
>> of time I don't expect to have for a while. It looks good
>> to happen, but don't hold supper for me.
> Do you want me to take a stab at it? It sounds like it was desirable
> to cut the current series into two halves? The core changes first, and
> the userspace interface changes next?

My read on it was a three phased approach:

First, move the cap "module" checks out of the other modules
and directly into security.c. There would be no "default" module.
If another module is loaded, call the hook it defines if the cap
check passes. Add /sys/kernel/security/lsm to make it easy to
find out what module (if any) is active.

Second, allow more than one LSM to get called if so requested.
Call them all, and return the error code of the last failure.
Refuse to load more than one module that uses an exclusive feature;
netlabel, secmark or XFRM.

Finally, put in all the gimmicks to decide who gets which of the
networking facilities.

Yes, If you've got the cycles to work with it I'd be happy for the help.


>
> -Kees
>


  parent reply	other threads:[~2013-10-18  2:25 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
2013-10-18  2:25               ` Casey Schaufler [this message]
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=52609C36.2040809@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.