mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Eric Paris <eparis@redhat.com>
To: James Morris <jmorris@namei.org>
Cc: linux-kernel@vger.kernel.org, sds@tycho.nsa.gov,
	selinux@tycho.nsa.gov, alan@redhat.com, chrisw@redhat.com,
	hpa@zytor.com, akpm@linux-foundation.org
Subject: Re: [PATCH 3/3] security: allow capable check to permit mmap or low vm space
Date: Tue, 20 Nov 2007 11:54:41 -0500	[thread overview]
Message-ID: <1195577681.2912.4.camel@localhost.localdomain> (raw)
In-Reply-To: <Xine.LNX.4.64.0711170911140.31014@us.intercode.com.au>

On Sat, 2007-11-17 at 09:12 +1100, James Morris wrote:
> On Fri, 16 Nov 2007, Eric Paris wrote:
> 
> > When this protection was originally concieved it intentionally was
> > offing something even without an more 'full featured' LSM.  That was the
> > whole reason I had to drop the secondary stacking hook inside the
> > selinux code.
> > 
> > While I now understand the question, I think that this is the behavior
> > most people would want.  I'll revert the security enhancement for
> > non-LSM systems if others agree with James, but I think adding another
> > small bit of protection against kernel flaws for everyone who wants
> > security is a win.  (and remember, in kernel we still default this to
> > off so noone is going to 'accidentally' see and security checks in the
> > dummy hooks)
> 
> If it's off by default and generally useful across LSMs, why not just put 
> it in the base kernel code?

It was placed in CONFIG_SECURITY so that users can (If their given LSM
supports it) selectively allow this stuff.  Some LSMs are fine grained
enough to allow applications like dosemu and X to use low pages without
globally disabling.  I can't think of any reasonable way to move all of
this into base kernel code while still allowing overrides.

I'd love to hear suggestions on how to move all of this out of the
security code and into the base kernel while not neglecting those few
users who need this functionality.

-Eric


      reply	other threads:[~2007-11-20 16:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-16 20:55 Eric Paris
2007-11-16 21:47 ` James Morris
2007-11-16 21:53   ` Eric Paris
2007-11-16 21:58     ` James Morris
2007-11-16 22:07       ` Eric Paris
2007-11-16 22:12         ` James Morris
2007-11-20 16:54           ` Eric Paris [this message]

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=1195577681.2912.4.camel@localhost.localdomain \
    --to=eparis@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=alan@redhat.com \
    --cc=chrisw@redhat.com \
    --cc=hpa@zytor.com \
    --cc=jmorris@namei.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@tycho.nsa.gov \
    /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

Powered by JetHome