[apparmor] Possible to record userland EIP/RIP (instruction pointer) in audit logs?

[Seth Arnold]

On Wed, Mar 14, 2012 at 5:47 PM, John Johansen
<john.johansen at canonical.com> wrote:
> On 03/14/2012 04:20 PM, Number Six wrote:
>> On Wed, Mar 14, 2012, at 02:52 PM, John Johansen wrote:
>>> On 03/14/2012 02:21 PM, Number Six wrote:
>>>> I am dealing with a possible exploit that seems to irregularly
>>>> attempt to execute a series of suspicious system calls, and I'd like
>>>> to try to dive in with gdb to see what is really going on.

> A more common case is wanting the syscall parameters and that we can do if
> you install auditd, and turn on syscall auditing with
>
>  sudo auditctl -e 1
>
> then every apparmor reject is accompanied by a syscall entry in the audit
> log.  However after poking at it for a bit it doesn't seem possible to
> get the EIP as part of the audit message.
>
> So if you need a custom patch, I can do that.

A possible way to make this a bit more generic could extend the
APPARMOR_ENFORCE, APPARMOR_COMPLAIN, APPARMOR_KILL profile flags to also
include APPARMOR_CORE or APPARMOR_STOP that asks for a core dump or asks
for SIGSTOP to be sent to the process. Either of these would make it
easier to inspect a process that has violated policy at the moment the
policy violation takes place.

One possible way to get _some_ data without patching the runtime system
could run 'ps -oeip pid' immediately after the DENIED message is
generated. It'll race with the process to discover the EIP, but you might
get lucky and find the process asleep still. I'm thinking, if you write a
small script that runs tail -f /var/log/audit/audit.log and kicks off
the ps command (or does the introspection itself via /proc/pid/stat)
immediately upon noticing the DENIED output. If you run it with SCHED_FIFO
or SCHED_RR, it might win the race against the exploited process.