From: Daniel J Walsh <dwalsh@redhat.com>
To: Steve Grubb <sgrubb@redhat.com>
Cc: linux-audit@redhat.com
Subject: Re: auditing syscalls made 'by' an inode?
Date: Fri, 08 Jun 2012 10:49:48 -0400 [thread overview]
Message-ID: <4FD2110C.3080400@redhat.com> (raw)
In-Reply-To: <201206080951.25371.sgrubb@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-----
next prev parent reply other threads:[~2012-06-08 14:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-07 22:31 auditing syscalls made 'by' an inode? Peter Moody
2012-06-08 13:35 ` Steve Grubb
2012-06-08 13:51 ` Steve Grubb
2012-06-08 14:49 ` Daniel J Walsh [this message]
2012-06-08 15:36 ` Peter Moody
2012-06-08 16:01 ` Steve Grubb
2012-06-08 16:01 ` Casey Schaufler
2012-07-03 22:02 ` Peter Moody
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FD2110C.3080400@redhat.com \
--to=dwalsh@redhat.com \
--cc=linux-audit@redhat.com \
--cc=sgrubb@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox