Re: Using a watch to find who is using a file

[Steve Grubb <sgrubb@redhat.com>]

On Monday, January 04, 2016 04:49:13 PM Maupertuis Philippe wrote:
> Hi list
> Our dbas complained that vim swap file were renamed instead of being deleted
> With an audit watch we were able to tell them to stop their silly cron 
> rename job :) However, the audit log is missing an important piece of
> information : the job name.

Yes. I opened a bz on this about a month ago.
https://bugzilla.redhat.com/show_bug.cgi?id=1288653


> It seems that we didn't capture the exe name associated with the parent pid.

We never do.


> If I am no misunderstanding the results
> below,  pid = 28351 is for the exe /bin/mv

Yes.


> I would have liked to know the exe of the parent pid

That would be useful in many cases, but the parent process could have exited 
by the time the child process triggers the event. So, its not really possible. 

That said, people really do want something. For example, maybe someone knows 
an exploit and can get a command injection through apache which then gives 
them a shell and they start doing things to escalate privileges. In this case, 
you not only want the ppid, you want the whole chain of processes to see how 
someone got into the system. A bz was opened to do this:

https://bugzilla.redhat.com/show_bug.cgi?id=1094156

There didn't seem to be anyone who thought this was a good idea.


> Is there a way to ensure that the audit log includes the executable name
> associated with every pid ? Or  the exe associated with pid starting a new
> session ?

You could log all clone & execve syscalls. :-)

 
> What we did was :
> 
> To find out how vim swap files were renamed without the leading dot a the
> following rule was inserted : auditctl -w /etc/mysql -p war -k test_swp
> which gave us the following result :
> ----
> type=PATH msg=audit(12/22/2015 11:45:01.766:1660580) : item=3
> name=param-MYLHCE01V.swp inode=49283 dev=fd:00 mode=file,640 ouid=root
> ogid=root rdev=00:00 nametype=CREATE type=PATH msg=audit(12/22/2015
> 11:45:01.766:1660580) : item=2 name=.param-MYLHCE01V.swp inode=49283
> dev=fd:00 mode=file,640 ouid=root ogid=root rdev=00:00 nametype=DELETE
> type=PATH msg=audit(12/22/2015 11:45:01.766:1660580) : item=1
> name=/etc/mysql inode=49308 dev=fd:00 mode=dir,755 ouid=mysql ogid=mysql
> rdev=00:00 nametype=PARENT type=PATH msg=audit(12/22/2015
> 11:45:01.766:1660580) : item=0 name=/etc/mysql inode=49308 dev=fd:00
> mode=dir,755 ouid=mysql ogid=mysql rdev=00:00 nametype=PARENT type=CWD
> msg=audit(12/22/2015 11:45:01.766:1660580) :  cwd=/etc/mysql type=SYSCALL
> msg=audit(12/22/2015 11:45:01.766:1660580) : arch=x86_64 syscall=rename
> success=yes exit=0 a0=0x7ffe46229db3 a1=0x7ffe46229dc8 a2=0x0
> a3=0x7ffe46227c80 items=4 ppid=28254 pid=28351 auid=mysql uid=mysql
> gid=mysql euid=mysql suid=mysql fsuid=mysql egid=mysql sgid=mysql
> fsgid=mysql tty=(none) ses=276356 comm=mv exe=/bin/mv key=swp_move
> 
> Searching for the whole session gave us :

In this particular case, the cron patch might help. But overall, cases like 
this really want the chain of processes to know the complete origin of 
processes involved.

-Steve