On Thu, 2005-12-08 at 16:29 -0500, Daniel J Walsh wrote: > http://people.redhat.com/drepper/selinux-mem.html The description of execmem says: "The solution for the anonymous case is to create the memory region without execution permission and then, when the wanted content is created, change the permission to include PROT_EXEC but not PROT_WRITE." But this will still trigger an execmem check, as the check is applied upon mmap or mprotect for anonymous mappings with PROT_EXEC, irrespective of PROT_WRITE, in order to control the ability to execute arbitrary memory (not just to control the ability to execute currently writable memory). In the case of private file mappings, it is handled differently, with execmem only applied upon mmap or mprotect with PROT_EXEC and PROT_WRITE simultaneously, and execmod applied upon PROT_EXEC by itself after a prior modification. > We are planning on turning off allow_execmem, allow_execmod, > allow_execheap for unconfined_t in targeted policy. We are working to > clean up any problems this might cause. This will add additional > security features to Userspace, but might cause headaches. > > If you have the latest policy installed on Rawhide > > selinux-policy-targeted-2.1.0-3 or later you can try it out by running > > setsebool -P allow_execmem=0 allow_execmod=0 allow_execheap=0 There is no allow_execheap, but there is an allow_execstack. Note that turning off allow_execmem should also disable execstack; execmem covers a superset of what execstack covers. If you need runtime code generation, you can enable execmem while disabling execstack to retain protection of the stack while permitting generation of code to other anonymous memory. -- Stephen Smalley National Security Agency -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
