Hooks and stacking

From: John Richard Moser (nigelenki@private)
Date: Wed Mar 30 2005 - 17:52:56 PST


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

Which version of Linux will first implement stacking in LSM as per Serge
Hallyn's patches?

Where is the new documentation?


As for hooks, a few questions.

1.  With shm_shmctl(), can I control permissions assigned to shared
memory using shmctl()?  I want to prevent memory protections on the shm
segment from being in certain combinations; however, if any changes
AFTER creation go through mprotect(), I can use file_mprotect() because
I will be preventing the same transitions everywhere.

2.  What is the best hook to use to catch allocation of a shared memory
segment and control the permissions assigned to it?  I want a shared
memory segment to always be created without PROT_EXEC.

3.  I want control over the memory protections on the stack and heap.
PT_GNU_STACK allows for an executable stack/heap.  Is there a way for me
to control this so that I can i.e. mandatorily make the stack/heap
PROT_READ|PROT_WRITE and never PROT_EXEC?  The only way I can see is to
add a hook in load_elf_binary(). . . .


In case anyone is wondering, as an excercise (but potentially as
something I may aim at mainline), I'm trying to port some of the stuff
from PaX into an LSM; particularly, the memory protection enhancements.
 As a proof of concept, I'm considering supporting PT_PAX_FLAGS from the
module; but I'm also considering a security label.  My concern with a
security label is conflicting with SeLinux and having issues with ReiserFS.

Particularly, I'm trying to port over stuff from
http://pax.grsecurity.net/docs/mprotect.txt

I would not be so insane as to attempt to place ASLR into a security
module; it could be done if the right hooks were there, but the results
would be insane, and mixing such modules would be dangerous.  When
2.6.12 rolls around with ASLR, however, I may consider taking a crack at
it.  Controling (increasing to a predefined maximum) the entropy of the
ASLR in bits may be viable.  Brute force deterrance (from GrSecurity)
may also be viable in an LSM, but is useless with very small order ASLR.

- --
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.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCS1f3hDd4aOud5P8RAu9iAJ9HpM8Y4xFbJzS8ByNYYJBxZyz0jgCePYbp
shJWHFPrfP2hLH4JInFuZ0g=
=lK/u
-----END PGP SIGNATURE-----



This archive was generated by hypermail 2.1.3 : Wed Mar 30 2005 - 17:53:18 PST