allow execmod and execmem for self debugging process [targeted]

Stephen Smalley sds at
Mon Jun 20 14:44:34 UTC 2005

On Sun, 2005-06-19 at 12:18 -0700, John Reiser wrote:
> 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
> 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.

execmem is purely a task-self check, i.e. a process can either make an
anonymous mapping executable (and thus execute arbitrary code) or not.
execmod is a task-file check to allow finer granularity for the case of
text relocations; it is applied when a process attempts to make a
modified private file mapping executable, which normally only occurs for
text relocations.  Thus, under strict policy, execmod is normally
restricted to a particular file type (texrel_shlib_t) and all files
requiring text relocation must be explicitly labeled with that type in
order to allow the relocation.  allow_execmod just controls whether or
not execmod is _ever_ allowed, but even when it is enabled, you are
still limited to texrel_shlib_t.

Under targeted policy, it appears that a wider set of file types is
allowed by allow_execmod, including common shared objects and
executables, and there have been discussions on this list about
extending it to all file types by default there.

Stephen Smalley
National Security Agency

More information about the fedora-selinux-list mailing list