auditing syscalls made 'by' an inode?

auditing syscalls made 'by' an inode?

[Peter Moody]

Is there anyway to audit syscalls made by a particular, not yet
running, application? 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?

Cheers,
peter

-- 
Peter Moody      Google    1.650.253.7306
Security Engineer  pgp:0xC3410038

Re: auditing syscalls made 'by' an inode?

[Steve Grubb]

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...

-Steve

Re: auditing syscalls made 'by' an inode?

[Steve Grubb]

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

Re: auditing syscalls made 'by' an inode?

[Daniel J Walsh]

-----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-----

Re: auditing syscalls made 'by' an inode?

[Peter Moody]

On Fri, Jun 8, 2012 at 7:49 AM, Daniel J Walsh <dwalsh@redhat.com> wrote:

> 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.

True, but this requires running selinux, which despite all of the
excellent work you guys have put into making that easy (easier), is
still a non-starter for some people.

Cheers,
peter

-- 
Peter Moody      Google    1.650.253.7306
Security Engineer  pgp:0xC3410038

Re: auditing syscalls made 'by' an inode?

[Steve Grubb]

On Friday, June 08, 2012 11:36:38 AM Peter Moody wrote:
> On Fri, Jun 8, 2012 at 7:49 AM, Daniel J Walsh <dwalsh@redhat.com> wrote:
> > 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.
> 
> True, but this requires running selinux, which despite all of the
> excellent work you guys have put into making that easy (easier), is
> still a non-starter for some people.

I agree. I'd like to see the capability developed out because it might allow new 
kinds of auditing. Like...you might want to audit syscalls with EPERM started by 
apache and not under the httpd_t selinux context. :-)

-Steve

Re: auditing syscalls made 'by' an inode?

[Casey Schaufler]

On 6/8/2012 7:49 AM, Daniel J Walsh wrote:
> -----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-----

It seems that an audit mask attribute on the program file,
much like the file capability attribute, would be on obvious
enhancement to address the original problem statement. The
file capability code could serve as a template. This would be
a generally useful facility in today's application oriented
environments.

I expect that the SELinux based suggestions will work so long
as you're OK with running SELinux and you're sufficiently
confident in your policy writing skills that you can feel
safe changing the policy on important applications. I have
no doubts that Daniel could fix up any policy under the sun
to get auditing without breaking any other enforcement. I
also know that I would never try it.


>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
>

Re: auditing syscalls made 'by' an inode?

[Peter Moody]

On Fri, Jun 8, 2012 at 6:51 AM, Steve Grubb <sgrubb@redhat.com> 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.

Hi Al,

Steve mentioned that you had some ideas about how the implementation
for this might look. Before I spend a bunch of time (probably mostly
spinning my wheels trying to fully understand what's going on
underneath) coming up with something that doesn't pass muster, would
you be able to point me in the right direction?

Cheers,
peter

> 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



-- 
Peter Moody      Google    1.650.253.7306
Security Engineer  pgp:0xC3410038