linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: James Morris <jmorris@namei.org>, Kees Cook <keescook@chromium.org>
Cc: linux-kernel@vger.kernel.org,
	James Morris <james.l.morris@oracle.com>,
	linux-security-module@vger.kernel.org,
	Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: [PATCH] LSM: ModPin LSM for module loading restrictions
Date: Thu, 17 Oct 2013 10:26:48 -0700	[thread overview]
Message-ID: <52601DD8.7090308@schaufler-ca.com> (raw)
In-Reply-To: <alpine.LRH.2.02.1310171858170.32257@tundra.namei.org>

On 10/17/2013 1:02 AM, James Morris wrote:
> This seems like a regression in terms of separating mechanism and policy.  
>
> We have several access control systems available (SELinux, at least) which 
> can implement this functionality with existing mechanisms using dynamic 
> policy.

They said the same thing about Smack.

The problem there is that you have to buy into the entirety of
SELinux to implement a small bit of behavior. You have to write
a policy that takes every aspect of system behavior into account
when all you care about is loading restrictions on modules.

If you want all of SELinux you still have to define your problem
in a subject/object model. That may be possible, but in this
case at least it certainly ain't obvious.

> I'm concerned about the long term architectural impact of a proliferation 
> of arbitrary hard-coded security policies in the kernel.  I don't 
> understand the push in this direction, frankly.

The rationale is that lots of people doing little things is
likely to get us relevant security in a reasonable amount of time.
The existing LSMs reflect 20th century technologies and use cases.
They are fine for multi-user timesharing systems. We need to move
forward to support networked gaming, phones, tablets and toasters.

>
> On Fri, 20 Sep 2013, Kees Cook wrote:
>
>> ...
>> -- 
>> 1.7.9.5
>>
>>
>> -- 
>> Kees Cook
>> Chrome OS Security
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>>
>


  parent reply	other threads:[~2013-10-17 17:26 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
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 [this message]
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=52601DD8.7090308@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 \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).