allow execmod and execmem for self debugging process [targeted]

[John Reiser]

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.

--

having trouble getting dhcpd started

[Jon August]

Hi there,

I just installed FC4 and I'm trying to get DHCP started, so I pulled  
my dhcpd.conf from the machine we're moving it from, and checked to  
see if any of the syntax had changed.  All looks good, but when I try  
to start dhcpd I get the following.

Is SELinux preventing dhcp from binding to the port?  I don't see any  
audit messages in /var/log/messages.

There are no other dhcp servers running on this machine or the rest  
of the network for that matter.

Thanks,
      -Jon

Jun 19 15:39:17 fc4machine dhcpd: Internet Systems Consortium DHCP  
Server V3.0.2
Jun 19 15:39:17 fc4machine dhcpd: Copyright 2004 Internet Systems  
Consortium.
Jun 19 15:39:17 fc4machine dhcpd: All rights reserved.
Jun 19 15:39:17 fc4machine dhcpd: For info, please visit http:// 
www.isc.org/sw/dhcp/
Jun 19 15:39:17 fc4machine dhcpd: Wrote 0 deleted host decls to  
leases file.
Jun 19 15:39:17 fc4machine dhcpd: Wrote 0 new dynamic host decls to  
leases file.
Jun 19 15:39:17 fc4machine dhcpd: Wrote 0 leases to leases file.
Jun 19 15:39:17 fc4machine dhcpd: Listening on LPF/ 
eth0/00:11:43:d8:ec:21/208.226.79/24
Jun 19 15:39:17 fc4machine dhcpd: Sending on   LPF/ 
eth0/00:11:43:d8:ec:21/208.226.79/24
Jun 19 15:39:17 fc4machine dhcpd: Can't bind to dhcp address:  
Permission denied
============================^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Jun 19 15:39:17 fc4machine dhcpd: Please make sure there is no other  
dhcp server
Jun 19 15:39:17 fc4machine dhcpd: running and that there's no entry  
for dhcp or
Jun 19 15:39:17 fc4machine dhcpd: bootp in /etc/inetd.conf.   Also  
make sure you
Jun 19 15:39:17 fc4machine dhcpd: are not running HP JetAdmin  
software, which
Jun 19 15:39:17 fc4machine dhcpd: includes a bootp server.
Jun 19 15:39:17 fc4machine dhcpd:
Jun 19 15:39:17 fc4machine dhcpd: If you did not get this software  
from ftp.isc.org, please
Jun 19 15:39:17 fc4machine dhcpd: get the latest from ftp.isc.org and  
install that before
Jun 19 15:39:17 fc4machine dhcpd: requesting help.
Jun 19 15:39:17 fc4machine dhcpd:
Jun 19 15:39:17 fc4machine dhcpd: If you did get this software from  
ftp.isc.org and have not
Jun 19 15:39:17 fc4machine dhcpd: yet read the README, please read it  
before requesting help.
Jun 19 15:39:17 fc4machine dhcpd: If you intend to request help from  
the dhcp-server(a)isc.org
Jun 19 15:39:17 fc4machine dhcpd: mailing list, please read the  
section on the README about
Jun 19 15:39:17 fc4machine dhcpd: submitting bug reports and requests  
for help.
Jun 19 15:39:17 fc4machine dhcpd:
Jun 19 15:39:17 fc4machine dhcpd: Please do not under any  
circumstances send requests for
Jun 19 15:39:17 fc4machine dhcpd: help directly to the authors of  
this software - please
Jun 19 15:39:17 fc4machine dhcpd: send them to the appropriate  
mailing list as described in
Jun 19 15:39:17 fc4machine dhcpd: the README file.
Jun 19 15:39:17 fc4machine dhcpd:
Jun 19 15:39:17 fc4machine dhcpd: exiting.
Jun 19 15:39:17 fc4machine dhcpd: dhcpd startup failed

having trouble getting dhcpd started

[Ivan Gyurdiev]

On Sun, 2005-06-19 at 15:53 -0400, Jon August wrote:
>  Hi there,
>  
>  I just installed FC4 and I'm trying to get DHCP started, so I pulled  
>  my dhcpd.conf from the machine we're moving it from, and checked to  
>  see if any of the syntax had changed.  All looks good, but when I try  
>  to start dhcpd I get the following.
>  
>  Is SELinux preventing dhcp from binding to the port?  I don't see any  
>  audit messages in /var/log/messages. 
What about /var/log/audit.log ?
Is audit running?

You can run SELinux in permissive mode to check. 
(/usr/sbin/setenforce 0; 
/etc/init.d/dhcpd restart; 
/usr/sbin/setenforce 1;)

[Stephen Smalley]

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