From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel J Walsh Subject: Re: auditing syscalls made 'by' an inode? Date: Fri, 08 Jun 2012 10:49:48 -0400 Message-ID: <4FD2110C.3080400@redhat.com> References: <201206080935.01600.sgrubb@redhat.com> <201206080951.25371.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <201206080951.25371.sgrubb@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/08/2012 09:51 AM, Steve Grubb 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. > > 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@redhat.com > https://www.redhat.com/mailman/listinfo/linux-audit > On thing you could do would be to write a simple SELinux domain, like auditproc_t and have unconfined_t transition to it using runcon. type auditproc_t; domain_type(auditproc_t); unconfined_domain(auditproc_t) gen_require(` type unconfined_t; type unconfined_r; ') allow unconfined_t auditproc_t:process transition; role unconfined_r types auditproc_t; Setup audit rules to watch SELinux context auditproc_t. Then use runcon -t auditproc_t chrome Above is totally untested. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/SEQwACgkQrlYvE4MpobPO5QCgxjoEHO4F3tr6GWFPdBumCTkC kDcAn0+BhECihfFwlnjDHLoYw2WPnkvr =3vLI -----END PGP SIGNATURE-----