A self-debugging process wants arbitrary mmap() and mprotect() on itself, but gets EACCES with "avc: denied { execmod }" when it tries. What needs to be done to allow this? There are three cases: a) well-known named filesystem path as most-recent execve() b) process with "self-debug" as leaf name of most-recent execve() c) any execve() of a file with some assignable attribute [context]
Using selinux-policy-targeted-1.23.16-6 enforcing under Fedora Core 4 kernel-2.6.11-1.1369_FC4, I see complaints such as ---- type=AVC_PATH msg=audit(1119151560.280:466428): \ path="/path/to/self-debugger/shared-library" type=SYSCALL msg=audit(1119151560.280:466428): arch=40000003 syscall=125 per=400000 \ success=no exit=-13 a0=3000 a1=1000 a2=5 a3=0 items=0 pid=2701 auid=4294967295 \ uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 \ comm="self-debug" exe="/path/to/self-debugger/self-debug" type=AVC msg=audit(1119151560.280:466428): avc: denied { execmod } for pid=2701 \ comm="self-debug" name=shared-library dev=hda7 ino=4104583 \ scontext=user_u:system_r:unconfined_t tcontext=system_u:object_r:file_t tclass=file ---- Booting the kernel with "enforcing=0" allows the mprotect() to succeed; auditd.log still shows similar messages, except with "success=yes exit=0". I'd like to retain the safeguards of the targeted enforcing policy, but allow "known cases" the capabilities that they need. [Yes, this is a technique that malware may try to exploit. "Bonware" deserves the chance to exploit it, too.]
/etc/selinux/targeted/booleans has ----- allow_execmod=1 allow_execmem=1 ----- Shouldn't these two values have allowed any mprotect?
The self-debugger wants to re-write PROT_EXEC + MAP_PRIVATE pages of itself and other files that have been mmap()ed into the same process. Code in .a archive library such as http://BitWagon.com/tub/tub.html gives an application more control over its address space by "hooking" all mmap(), etc. Complicated watchpoints run thousands of times faster in contrast to requiring ptrace() by a second process [gdb], etc.