SELinux policies, memory protections

[John Richard Moser <nigelenki@comcast.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I was writing a section of my paper ("Designing a Secure and Friendly
Operating System") and basically describing and explaining why the
memory protection policy ("mprotect() restrictions") supplied by PaX is
a powerful security tool; and I had a thought.  PaX places the policy in
the kernel; but with LSM hooks in mprotect() and friends, it may be
possible to implement it entirely in policy.  This would be interesting,
as it would allow a system implementing the suggested enhancements to
avoid additional kernel code.

What I want to know is, what facilities does SELinux supply in the
current policy format to control the abuse of mprotect(), mmap(), and
friends; and where can I find an online reference on this?

For reference, PaX defines the following "good" mapping states where new
code can't be introduced (note that VM_READ and VM_MAYREAD are
completely ignored as they are of no consequence):

      VM_WRITE
      VM_MAYWRITE
      VM_WRITE | VM_MAYWRITE
      VM_EXEC
      VM_MAYEXEC
      VM_EXEC | VM_MAYEXEC

Of course the kernel won't allow VM_WRITE or VM_EXEC without VM_MAYWRITE
or VM_MAYEXEC, so this leaves us with

      VM_MAYWRITE
      VM_MAYEXEC
      VM_WRITE | VM_MAYWRITE
      VM_EXEC | VM_MAYEXEC


This gives us a few target guarantees:

1.  No mapping may be created in any state other than those listed above
(VM_READ and VM_READ|VM_MAYREAD are permissible in addition to any
allowed state)

2.  No mapping may transition to any state not described in (1)

3.  No existing mapping without VM_EXEC is to have VM_MAYEXEC or be
given VM_EXEC or VM_MAYEXEC at any time in the remainder of its life
cycle; this includes mappings that started with and later dropped VM_EXEC



And there are a few other things that I want guaranteed:

1.  Anonymous mappings are always created without VM_EXEC or VM_MAYEXEC

2.  Shared memory mappings are always created without VM_EXEC or
VM_MAYEXEC (this is the current case)

3.  File backed mmap() segments requesting PROT_WRITE get
VM_WRITE|VM_MAYWRITE (and VM_READ|VM_MAYREAD if PROT_READ was
requested), but never VM_EXEC or VM_MAYEXEC even if requested

4.  For certain applications, it may be necessary that we can
automatically grant VM_EXEC|VM_MAYEXEC on file-backed mappings not
requesting PROT_WRITE, if those applications assume that PROT_READ
implies PROT_EXEC (this is how PaX works)


Finally, the ability to detect if the affected area is part of a
relocation and account for that in policy would be important, because
PaX set to disable ELF text relocations breaks quite a number of things;
trying to reconstruct the memory policy from PaX with an SELinux policy
without being able to mimic the special case allowance of ELF text
relocations would be disasterous.



REFERENCES:

  http://pax.grsecurity.net/docs/mprotect.txt


- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

    Creative brains are a valuable, limited resource. They shouldn't be
    wasted on re-inventing the wheel when there are so many fascinating
    new problems waiting out there.
                                                 -- Eric Steven Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC/r/+hDd4aOud5P8RAkCIAJ4utVh8rEZqLb3WDvM75gnkZ/+LOgCaAizc
zTSxkvYL0MFtC+QqEt//hbA=
=idfj
-----END PGP SIGNATURE-----
-
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/