auditing syscalls made 'by' an inode?

Peter Moody pmoody at google.com
Tue Jul 3 22:02:28 UTC 2012


On Fri, Jun 8, 2012 at 6:51 AM, Steve Grubb <sgrubb at redhat.com> wrote:
> On Friday, June 08, 2012 09:35:01 AM Steve Grubb wrote:
>> On Thursday, June 07, 2012 06:31:47 PM Peter Moody wrote:
>> > Is there anyway to audit syscalls made by a particular, not yet
>> > running, application?
>>
>> No...its one of the things I've been interested in for a long time. About
>> as close as you get is using the selinux process context. But if its
>> bin_t...there's a couple thousand processes with the same label.
>>
>> > For example, if I'm interested in seeing all
>> > exec's by google-chrome, can I do something like the following?
>> >
>> > auditctl -a exit,always -F arch=b64 -S execve -F success=1 -F
>> > inode=inode-of-chrome
>> >
>> > experimenting seems to indicate that will only tell me when
>> > inode-of-chrome is exec'd, basically a watch rule.
>> >
>> > The sort of inverse of this rule that got me thinking about this
>> > initially was auditing a syscall and seeing if it was/wasn't called by
>> > a particular program. For example, audting all bind() calls which
>> > *aren't* made by chrome (a silly rule to be sure, but just thrown out
>> > as a hypothetical)
>> >
>> > If it's not possible to do this now, is there interest in adding this
>> > feature?
>>
>> Yes. I'd be interested in seeing this available. But if you do implement
>> it, its more natural to express the rule by process name. But the kernel
>> does not do string comparisons. So, what you would likely need to do is
>> lookup the path to get the inode, then when it executes a new kind of pid
>> rule gets created probably off the list like watches do. There are some
>> apps like apache which fork multiple copies and that adds a wrinkle
>> because you would want to audit all of them. And then there are
>> threads...
>
> The other thing that was discussed a lot maybe 5 years ago (and I don't think it
> was ever created) was the ability to audit syscalls of a processes children and
> their children...on and on.  I think Al Viro mentioned he had some ideas about
> how to do this. But if you add audit by process name, its only natural to
> optionally track all child processes, too.

Hi Al,

Steve mentioned that you had some ideas about how the implementation
for this might look. Before I spend a bunch of time (probably mostly
spinning my wheels trying to fully understand what's going on
underneath) coming up with something that doesn't pass muster, would
you be able to point me in the right direction?

Cheers,
peter

> Where you might want this is like setting a rule on apache for any EPERM or any
> access to /home. Same could go for bind.
>
> -Steve
>
> --
> Linux-audit mailing list
> Linux-audit at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit



-- 
Peter Moody      Google    1.650.253.7306
Security Engineer  pgp:0xC3410038




More information about the Linux-audit mailing list