On an F8 system with vm.mmap_min_addr = 65535 when logging onto my X session I get an selinux denial from mono. time->Mon Dec 10 11:31:54 2007 type=SYSCALL msg=audit(1197304314.200:45): arch=40000003 syscall=192 per=400000 success=no exit=-13 a0=1000 a1=2000 a2=3 a3=22 items=0 ppid=1 pid=4799 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="mono" exe="/usr/bin/mono" subj=system_u:system_r:mono_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1197304314.200:45): avc: denied { mmap_zero } for pid=4799 comm="mono" scontext=system_u:system_r:mono_t:s0-s0:c0.c1023 tcontext=system_u:system_r:mono_t:s0-s0:c0.c1023 tclass=memprotect What this really means is that /usr/bin/mono tried get address space < 65536 available. Typically this means it tried to call mmap (or mremap) with MAP_FIXED and an address < 65536 (it could also be stack expansion and some other things, but mmap() of 0 is by far the most common. In trying to harden the kernel against escalation of priveledge attacks we are no longer allowing these types of operations. I'm not sure what mono was doing during start up (pretty much just a stock F8 plus the sysctl change) or why it needs to get access to this page. But we either need to figure out why it is required or we need to fix mono to stop doing this. I will be turning these protections on by default in F9 and hopefully in RHEL5.2 as well. Please explain why mono is doing this as soon as possible and even better, make it stop. -Eric
Just noticed I don't see tomboy running, was it tomboy that broke because of this?
This is from the garbage collector. For heap allocation it uses mmap with MAP_FIXED at the end of the last returned allocation as a hint to get a compact heap (I believe). The initial value used is HEAP_START, which for linux is (from libgc/include/private/gcconfig.h): # define HEAP_START (ptr_t)0x1000 /* This encourages mmap to give us low addresses, */ /* thus allowing the heap to grow to ~3GB */ To verify this, i tried vm.mmap_min_addr=4096 => OK, but vm.mmap_min_addr=4097 => not OK. Its easy to bump the HEAP_START to a larger value, but is there actually a security advantage in having mmap_min_addr > 4096?
BTW. This is the boehm garbage collector, used in many other apps. In fact, gcc uses it for its java gc, and it seems to pick 0x1000 for HEAP_START too: http://gcc.gnu.org/viewcvs/trunk/boehm-gc/include/private/gcconfig.h?revision=127506&view=markup&pathrev=127506
closing. not a bug. sorry, i should have been using an F9 kernel which deals with low HINT addresses. F9 kernel (and the future RHEL5 kernel) handles low hint addresses just fine (by rounding them up to min_addr. This would still blow up with MAP_FIXED, but with when it's only a hint no reason we should EPERM it.