Using a watch to find who is using a file

Using a watch to find who is using a file

[Maupertuis Philippe]

[-- Attachment #1.1: Type: text/plain, Size: 6020 bytes --]

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.
It seems that we didn't capture the exe name associated with the parent pid .
If I am no misunderstanding the results below,  pid = 28351 is for the exe /bin/mv

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

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 ?

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 :

----
type=LOGIN msg=audit(12/22/2015 11:45:01.458:1660551) : pid=28174 uid=root old auid=unset new auid=mysql old ses=unset new ses=276356
----
type=USER_START msg=audit(12/22/2015 11:45:01.468:1660570) : user pid=28174 uid=root auid=mysql ses=276356 msg='op=PAM:session_open acct=mysql exe=/usr/sbin/crond hostname=? addr=? terminal=cron res=success'
----
type=CRED_DISP msg=audit(12/22/2015 11:45:01.932:1660589) : user pid=28174 uid=mysql auid=mysql ses=276356 msg='op=PAM:setcred acct=mysql exe=/usr/sbin/crond hostname=? addr=? terminal=cron res=success'
----
type=USER_END msg=audit(12/22/2015 11:45:01.932:1660590) : user pid=28174 uid=mysql auid=mysql ses=276356 msg='op=PAM:session_close acct=mysql exe=/usr/sbin/crond hostname=? addr=? terminal=cron res=success'
----
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
----
type=PATH msg=audit(12/22/2015 11:45:01.767:1660581) : item=1 name=(null) inode=319568 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 nametype=NORMAL
type=PATH msg=audit(12/22/2015 11:45:01.767:1660581) : item=0 name=/bin/chmod inode=40985 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 nametype=NORMAL
type=CWD msg=audit(12/22/2015 11:45:01.767:1660581) :  cwd=/etc/mysql
type=EXECVE msg=audit(12/22/2015 11:45:01.767:1660581) : argc=3 a0=chmod a1=660 a2=param-MYLHCE01V.swp
type=SYSCALL msg=audit(12/22/2015 11:45:01.767:1660581) : arch=x86_64 syscall=execve success=yes exit=0 a0=0x7f5b008c2959 a1=0x7f5b008c26c8 a2=0x7f5b008c2828 a3=0x8 items=2 ppid=28254 pid=28355 auid=mysql uid=mysql gid=mysql euid=mysql suid=mysql fsuid=mysql egid=mysql sgid=mysql fsgid=mysql tty=(none) ses=276356 comm=chmod exe=/bin/chmod key=system_commands

Happy new year.
Philippe


________________________________

Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? de Worldline ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.

[-- Attachment #1.2: Type: text/html, Size: 11440 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

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

[Steve Grubb]

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