[PATCH 3/3] security: allow capable check to permit mmap or low vm space

[PATCH 3/3] security: allow capable check to permit mmap or low vm space

[Eric Paris]

On a kernel with CONFIG_SECURITY but without an LSM which implements
security_file_mmap it is impossible for an application to mmap addresses
lower than mmap_min_addr.  Based on a suggestion from a developer in the
openwall community this patch adds a check for CAP_SYS_RAWIO.  It is
assumed that any process with this capability can harm the system a lot
more easily than writing some stuff on the zero page and then trying to
get the kernel to trip over itself.  It also means that programs like X
on i686 which use vm86 emulation can work even with mmap_min_addr set.

Signed-off-by: Eric Paris <eparis@redhat.com>

---

 security/dummy.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/security/dummy.c b/security/dummy.c
index 6d895ad..3ccfbbe 100644
--- a/security/dummy.c
+++ b/security/dummy.c
@@ -426,7 +426,7 @@ static int dummy_file_mmap (struct file *file, unsigned long reqprot,
 			    unsigned long addr,
 			    unsigned long addr_only)
 {
-	if (addr < mmap_min_addr)
+	if ((addr < mmap_min_addr) && !capable(CAP_SYS_RAWIO))
 		return -EACCES;
 	return 0;
 }

Re: [PATCH 3/3] security: allow capable check to permit mmap or low vm space

[James Morris]

On Fri, 16 Nov 2007, Eric Paris wrote:

> On a kernel with CONFIG_SECURITY but without an LSM which implements
> security_file_mmap it is impossible for an application to mmap addresses
> lower than mmap_min_addr.

Actually, should we be doing any checking in the dummy module, given that 
it is not done with !CONFIG_SECURITY ?



- James
-- 
James Morris
<jmorris@namei.org>

Re: [PATCH 3/3] security: allow capable check to permit mmap or low vm space

[Eric Paris]

On Sat, 2007-11-17 at 08:47 +1100, James Morris wrote:
> On Fri, 16 Nov 2007, Eric Paris wrote:
> 
> > On a kernel with CONFIG_SECURITY but without an LSM which implements
> > security_file_mmap it is impossible for an application to mmap addresses
> > lower than mmap_min_addr.
> 
> Actually, should we be doing any checking in the dummy module, given that 
> it is not done with !CONFIG_SECURITY ?

I'm not sure I understand the question.  We already do a number of
capable type security checks in dummy functions. See dummy_settime() as
just one example.

If we have !CONFIG_SECURITY we don't have any security protections (how
could we?  we turned them off) so we don't get into dummy hooks.  If we
do checks or not in uncompiled code doesn't seem to me to matter.

Maybe I'm just confused...

-Eric

Re: [PATCH 3/3] security: allow capable check to permit mmap or low vm space

[James Morris]

On Fri, 16 Nov 2007, Eric Paris wrote:

> On Sat, 2007-11-17 at 08:47 +1100, James Morris wrote:
> > On Fri, 16 Nov 2007, Eric Paris wrote:
> > 
> > > On a kernel with CONFIG_SECURITY but without an LSM which implements
> > > security_file_mmap it is impossible for an application to mmap addresses
> > > lower than mmap_min_addr.
> > 
> > Actually, should we be doing any checking in the dummy module, given that 
> > it is not done with !CONFIG_SECURITY ?
> 
> I'm not sure I understand the question.  We already do a number of
> capable type security checks in dummy functions. See dummy_settime() as
> just one example.

I mean just in this case.  If no mmap_min_addr check is done without 
CONFIG_SECURITY, then perhaps none should be done in the dummy module, 
i.e. preserving existing behavior.  LSM is theoretically supposed to be 
unnoticable from a behavioral pov unless a non-dummy module is loaded.

> 
> If we have !CONFIG_SECURITY we don't have any security protections (how
> could we?  we turned them off) so we don't get into dummy hooks.  If we
> do checks or not in uncompiled code doesn't seem to me to matter.
> 
> Maybe I'm just confused...
> 
> -Eric
> 

-- 
James Morris
<jmorris@namei.org>

Re: [PATCH 3/3] security: allow capable check to permit mmap or low vm space

[Eric Paris]

On Sat, 2007-11-17 at 08:58 +1100, James Morris wrote:
> On Fri, 16 Nov 2007, Eric Paris wrote:
> 
> > On Sat, 2007-11-17 at 08:47 +1100, James Morris wrote:
> > > On Fri, 16 Nov 2007, Eric Paris wrote:
> > > 
> > > > On a kernel with CONFIG_SECURITY but without an LSM which implements
> > > > security_file_mmap it is impossible for an application to mmap addresses
> > > > lower than mmap_min_addr.
> > > 
> > > Actually, should we be doing any checking in the dummy module, given that 
> > > it is not done with !CONFIG_SECURITY ?
> > 
> > I'm not sure I understand the question.  We already do a number of
> > capable type security checks in dummy functions. See dummy_settime() as
> > just one example.
> 
> I mean just in this case.  If no mmap_min_addr check is done without 
> CONFIG_SECURITY, then perhaps none should be done in the dummy module, 
> i.e. preserving existing behavior.  LSM is theoretically supposed to be 
> unnoticable from a behavioral pov unless a non-dummy module is loaded.

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)

-Eric

Re: [PATCH 3/3] security: allow capable check to permit mmap or low vm space

[James Morris]

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?


- James
-- 
James Morris <jmorris@namei.org>

Re: [PATCH 3/3] security: allow capable check to permit mmap or low vm space

[Eric Paris]

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