3

So, I have this trio of audit log entries

type=AVC msg=audit(1488396169.095:2624951): avc:  denied  { setrlimit } for  pid=16804 comm="bash" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_t:s0 tclass=process
type=SYSCALL msg=audit(1488396169.095:2624951): arch=c000003e syscall=160 success=no exit=-13 a0=1 a1=7ffe06c17350 a2=2 a3=7fea949f3eb0 items=0 ppid=15216 pid=16804 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="bash" exe="/usr/bin/bash" subj=system_u:system_r:httpd_t:s0 key=(null)
type=EOE msg=audit(1488396169.095:2624951):

On the AVC line, it's easy enough to immediately see that a bash process with the system_u:system_r:httpd_t:s0 context was denied permission to set a resource limit.

On the SYSCALL line, a quick google for syscall=160 indicates that it's a setrlimit() call, which jives. What I don't know is what resource was requested to be modified. What resources was it trying to modify?

1

So, in this case, we already know that the syscall in question was setrlimit. A search for setrlimit reveals there's a C library function by the same name that wraps the syscall.

The function's documentation indicates that the first argument ("a0" in the SYSCALL line from the audit log) indicates the resource in question, but the manual only tells us symbol names, not numeric value. It does, however, tell us that the symbols are defined in the sys/resource.h header file. However, that file doesn't contain the actual values.

To get the numeric values, it turns out we look in sysdeps/unix/sysv/linux/bits/resource.h. There, we find the various RLIMIT_ macros defined.

Looking at those, we can find which resource was attempted to be modified. In this case, a0=1, and the macro corresponding to 1 turns out to be RLIMIT_FSIZE.

0

It is a bit different way. The AVC says, that you have bash process running and it is trying to set rlimit on itself or some of its children, which is quite common case for a shell.

What is wrong is that the bash is running with SELinux context of httpd service, which is not allowed to do that. It is not allowed, because httpd is network facing daemon and if there would be some bug, you don't want to allow attackers to play with this.

This is usually caused by the fact that the bash was started from the httpd somehow (which is quite much never a good idea to do).

From these messages you will not know what resource is being modified. SELinux has just the setrlimit capability, which allows or denies modification of any limits. When searching for arguments, you would need some different tool, such as:

  • SystemTap to investigate system calls and their arguments
  • Reading through the source code
  • Running your script under gdb or attaching gdb to running process.
  • I've edited the question to better reflect the precise meaning of the audit log lines. – Michael Mol Mar 1 '17 at 20:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.