Re: Using a watch to find who is using a file
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