All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Stephen Smalley <sds@epoch.ncsc.mil>
Cc: casey@schaufler-ca.com, "Serge E. Hallyn" <serue@us.ibm.com>,
	James Morris <jmorris@namei.org>,
	lkml <linux-kernel@vger.kernel.org>,
	linux-security-module@vger.kernel.org,
	Linux Containers <containers@lists.osdl.org>,
	Pavel Emelianov <xemul@openvz.org>
Subject: Re: [PATCH] cgroups: implement device whitelist lsm (v3)
Date: Mon, 17 Mar 2008 23:48:42 -0700	[thread overview]
Message-ID: <20080318064842.GA23167@kroah.com> (raw)
In-Reply-To: <1205760399.22912.183.camel@moss-spartans.epoch.ncsc.mil>

On Mon, Mar 17, 2008 at 09:26:39AM -0400, Stephen Smalley wrote:
> > > The original promise was that LSM would allow kernels to be built that
> > > shed capabilities altogether,
> > 
> > I don't remember that, but it's been a long time so it could be true.
> 
> "One of the explicit requirements to get LSM into the kernel was to have
> the ability to make capabilities be a module.  This allows the embedded
> people to completely remove capabilities, as they really want this.  I
> don't think we can ignore this, no matter how much of a pain in the butt
> it is :)" - Greg KH
> 
> Quoted from:
> http://marc.info/?l=linux-security-module&m=99236500727804&w=2
> 
> Ironically, since that time, capabilities have doubled in size and still
> can't be removed from the core kernel since LSM didn't push the state
> into the security blobs.

Maybe we need to seriously revisit this and perhaps rip capabilities
back out and put it always into the kernel if it's always a requirement.

Comments made 7 years ago might be totally wrong when we have now
learned how this all has worked out...

thanks,

greg k-h

  reply	other threads:[~2008-03-18  6:48 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-13 14:41 [PATCH] cgroups: implement device whitelist lsm (v3) Serge E. Hallyn
2008-03-14 10:17 ` James Morris
     [not found]   ` <Xine.LNX.4.64.0803142039460.32184-RC8Ws/H8zzudju81dFSl6rpzq4S04n8Q@public.gmane.org>
2008-03-14 13:27     ` Stephen Smalley
2008-03-14 13:27       ` Stephen Smalley
2008-03-14 14:32       ` Serge E. Hallyn
     [not found]         ` <20080314143216.GC9741-6s5zFf/epYLPQpwDFJZrxKsjOiXwFzmk@public.gmane.org>
2008-03-14 17:41           ` Stephen Smalley
2008-03-14 17:41             ` Stephen Smalley
2008-03-14 22:44             ` Casey Schaufler
2008-03-17 13:26               ` Stephen Smalley
2008-03-18  6:48                 ` Greg KH [this message]
2008-03-17 14:08               ` Serge E. Hallyn
2008-03-17 16:16                 ` Casey Schaufler
2008-03-17 16:16                   ` Casey Schaufler
2008-03-17 16:48                   ` Stephen Smalley

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=20080318064842.GA23167@kroah.com \
    --to=greg@kroah.com \
    --cc=casey@schaufler-ca.com \
    --cc=containers@lists.osdl.org \
    --cc=jmorris@namei.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=sds@epoch.ncsc.mil \
    --cc=serue@us.ibm.com \
    --cc=xemul@openvz.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 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.