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

[John Johansen]

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.
>>>
>>> I've dug around trying to intercept the system calls in gdb, but
>>> either the exploit is failure-prone, or something else is blocking
>>> easy reproduction of the audit events.
>>>
>> have you tried strace?  You should be able to correlate syscall
>> failures with apparmor denied messages
>>
>> Another possibility is ftrace or ltt-ng
> 
> The big problem with tracing is that I get these audit messages like
> once a week, at best. I also experienced instability with ltrace when I
> tried it. My best results so far when debugging a different set of audit
> messages came from using hardware watchpoints on the memory regions in
> a3
> from the audit logs, but in this instance they are changing from event
> to
> event.
> 
> I have not tried strace, ftrace or ltt-ng. I suppose I can give those
> a shot.. but a week's worth of recording any kind of tracing is going to
> get pretty big...
> 
>>> I'd be willing to test out a patch if that's what it takes.
>>>
>> that is a possibility but I would like to look at the more generic
>> solutions first.
> 
> I was pretty surprised that this wasn't a FAQ or frequently requested
> feature. It seems pretty basic to want to know the region of code that
> an audit message failed from, no? At least, I would expect more people
> to want a record of that than the memory address of the system call
> arguments (but both together would be very handy).
> 

Actually it has come up a few times, but I think strace has been sufficient
in most of those cases. I think I have done a custom patch to do this before
but the problem with that, at least several years ago was it was fairly
architecture specific or involved dumping the stack like an oops.

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.