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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.