allow execmod and execmem for self debugging process [targeted]

Stephen Smalley sds at tycho.nsa.gov
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  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.

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