Auditing write syscall

Auditing write syscall

[Ondra N.]

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

Hello,

I would like to ask a question about auditing write syscalls.  I am trying
to monitor all filesystem changes in a specific directory and process the
changes in near real time - audispd, was very helpful with that.

What concerns me is what if a filedescriptor is kept open for long periods
of time and written to once in a while? Only the open syscall is logged
when using a rule like this one.

auditctl -w /tmp/rnd_pop -p wa -k test_key

I was thinking that maybe being more explicit about what I want to do could
help like setting up a rule like this one.

auditctl -a always,exit -F dir=/tmp/rnd_pop -F perm=w -F succes=1 -k
test_key

But it doesnt seem to work for me, I guess I cannot filter write syscall by
directory because nothing ever shows up in the audit.log with a rule like
this.

What is the intended way to achieve logging of write syscalls in specific
directory, am i missing something? Should I check myself if the file is
still open when event is being processed and act accordingly?


Best regards,

Ondrej

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

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

Re: Auditing write syscall

[Steve Grubb]

Hello,

On Monday, May 13, 2019 3:43:54 PM EDT Ondra N. wrote:
> I would like to ask a question about auditing write syscalls.  I am trying
> to monitor all filesystem changes in a specific directory and process the
> changes in near real time - audispd, was very helpful with that.
> 
> What concerns me is what if a filedescriptor is kept open for long periods
> of time and written to once in a while? Only the open syscall is logged
> when using a rule like this one.
> 
> auditctl -w /tmp/rnd_pop -p wa -k test_key

Right. And if this triggers then you have to assume that the file was modified. 
In the past I worked with various upstream projects to have them open a 
descriptor read only and reopen when they need to modify files. This cuts down 
on false alarms.

> I was thinking that maybe being more explicit about what I want to do could
> help like setting up a rule like this one.
> 
> auditctl -a always,exit -F dir=/tmp/rnd_pop -F perm=w -F succes=1 -k
> test_key
> 
> But it doesnt seem to work for me, I guess I cannot filter write syscall by
> directory because nothing ever shows up in the audit.log with a rule like
> this.

The directory has to be immediately accessible to the syscall at the time of 
the syscall. When open is called, the path is immediately available as it is 
one of the syscall parameters. The write only has the FD which does not have 
the path associated with the FD accessible. Something in the kernel does keep 
this info around as the procfs has path info. But I think it's racey and 
could be stale  if you have a multithreaded app. 

I think there was some reason why this info cannot be used for path 
resolution for syscall filtering. I think Paul or Richard may need to answer 
why this cannot be used. Perhaps it could be that how do you know in a 
generic way based on any given syscall that one parameter is a file descriptor 
that can be cross referenced?

> What is the intended way to achieve logging of write syscalls in specific
> directory, am i missing something? Should I check myself if the file is
> still open when event is being processed and act accordingly?

I think some kinds of things will always be just out of reach for the audit 
system. Other tools like aide can help fill in the blanks. And there is also 
the fanotify interface where detailed change information can be gathered.

-Steve

Re: Auditing write syscall

[Richard Guy Briggs]

On 2019-05-14 09:55, Steve Grubb wrote:
> Hello,
> 
> On Monday, May 13, 2019 3:43:54 PM EDT Ondra N. wrote:
> > I would like to ask a question about auditing write syscalls.  I am trying
> > to monitor all filesystem changes in a specific directory and process the
> > changes in near real time - audispd, was very helpful with that.
> > 
> > What concerns me is what if a filedescriptor is kept open for long periods
> > of time and written to once in a while? Only the open syscall is logged
> > when using a rule like this one.
> > 
> > auditctl -w /tmp/rnd_pop -p wa -k test_key
> 
> Right. And if this triggers then you have to assume that the file was modified. 
> In the past I worked with various upstream projects to have them open a 
> descriptor read only and reopen when they need to modify files. This cuts down 
> on false alarms.
> 
> > I was thinking that maybe being more explicit about what I want to do could
> > help like setting up a rule like this one.
> > 
> > auditctl -a always,exit -F dir=/tmp/rnd_pop -F perm=w -F succes=1 -k
> > test_key
> > 
> > But it doesnt seem to work for me, I guess I cannot filter write syscall by
> > directory because nothing ever shows up in the audit.log with a rule like
> > this.
> 
> The directory has to be immediately accessible to the syscall at the time of 
> the syscall. When open is called, the path is immediately available as it is 
> one of the syscall parameters. The write only has the FD which does not have 
> the path associated with the FD accessible. Something in the kernel does keep 
> this info around as the procfs has path info. But I think it's racey and 
> could be stale  if you have a multithreaded app. 

The FD points to a struct file with struct path that includes a vfsmnt
and a dentry/inode, which could be used to create a PATH record, I
think.  A hook could be added to the write syscall to store it with
audit_file().  Similar hooks would need to be added to other syscalls
that read and access and execute FDs to round out that functionality.
This is already present for chmod, chown, f*xattr.  Having a generic
syscall parser that can detect these might be possible, but would
probably present an unacceptable performance hit.

I do have concerns that it could be racey and stale.

> I think there was some reason why this info cannot be used for path 
> resolution for syscall filtering. I think Paul or Richard may need to answer 
> why this cannot be used. Perhaps it could be that how do you know in a 
> generic way based on any given syscall that one parameter is a file descriptor 
> that can be cross referenced?

This is even Al Viro territory...

> > What is the intended way to achieve logging of write syscalls in specific
> > directory, am i missing something? Should I check myself if the file is
> > still open when event is being processed and act accordingly?
> 
> I think some kinds of things will always be just out of reach for the audit 
> system. Other tools like aide can help fill in the blanks. And there is also 
> the fanotify interface where detailed change information can be gathered.

Tracking the inode could work, but that would have to be dynamic to be
practical, I suspect, and likely the domain of *notify.

> -Steve

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635

Re: Auditing write syscall

[Paul Moore]

On Thu, May 23, 2019 at 5:12 PM Richard Guy Briggs <rgb@redhat.com> wrote:
> On 2019-05-14 09:55, Steve Grubb wrote:
> > Hello,
> >
> > On Monday, May 13, 2019 3:43:54 PM EDT Ondra N. wrote:
> > > I would like to ask a question about auditing write syscalls.  I am trying
> > > to monitor all filesystem changes in a specific directory and process the
> > > changes in near real time - audispd, was very helpful with that.
> > >
> > > What concerns me is what if a filedescriptor is kept open for long periods
> > > of time and written to once in a while? Only the open syscall is logged
> > > when using a rule like this one.
> > >
> > > auditctl -w /tmp/rnd_pop -p wa -k test_key
> >
> > Right. And if this triggers then you have to assume that the file was modified.
> > In the past I worked with various upstream projects to have them open a
> > descriptor read only and reopen when they need to modify files. This cuts down
> > on false alarms.
> >
> > > I was thinking that maybe being more explicit about what I want to do could
> > > help like setting up a rule like this one.
> > >
> > > auditctl -a always,exit -F dir=/tmp/rnd_pop -F perm=w -F succes=1 -k
> > > test_key
> > >
> > > But it doesnt seem to work for me, I guess I cannot filter write syscall by
> > > directory because nothing ever shows up in the audit.log with a rule like
> > > this.
> >
> > The directory has to be immediately accessible to the syscall at the time of
> > the syscall. When open is called, the path is immediately available as it is
> > one of the syscall parameters. The write only has the FD which does not have
> > the path associated with the FD accessible. Something in the kernel does keep
> > this info around as the procfs has path info. But I think it's racey and
> > could be stale  if you have a multithreaded app.

[Sorry, I saw Steve replied with a lot of text and assumed it had been
sufficiently answered, it wasn't until I saw Richard's reply that I
realized there were still lingering questions :)]

> The FD points to a struct file with struct path that includes a vfsmnt
> and a dentry/inode, which could be used to create a PATH record, I
> think.

Unfortunately you really can't reliably recreate the proper full path
after the fact because things can change at any given point in time.
The only time you can guarantee that a given pathname is valid, for a
particular process in a particular set of namespaces, is at the exact
point in time when the kernel resolves the pathname to a file.  I
would need to go look at the locking again, but I believe it is even
possible for the pathname to be valid during the open() syscall, but
be invalid by the time open() returns control to userspace.

> A hook could be added to the write syscall to store it with
> audit_file().  Similar hooks would need to be added to other syscalls
> that read and access and execute FDs to round out that functionality.
> This is already present for chmod, chown, f*xattr.  Having a generic
> syscall parser that can detect these might be possible, but would
> probably present an unacceptable performance hit.
>
> I do have concerns that it could be racey and stale.

If we cached it as you say in an audit specific struct (e.g.
audit_context), I think we could probably solve the race conditions
but it would require some bad locking and likely hooking
fd_install()/close_fd() and I *really* don't think we want to do that.
I would offer that auditing the various open()-esque syscalls and
assuming modifications (as Steve already described) is probably the
best option for the foreseeable future.

> > I think there was some reason why this info cannot be used for path
> > resolution for syscall filtering. I think Paul or Richard may need to answer
> > why this cannot be used. Perhaps it could be that how do you know in a
> > generic way based on any given syscall that one parameter is a file descriptor
> > that can be cross referenced?
>
> This is even Al Viro territory...

I'm sure Al would have some better commentary on this than me, but to
do this properly would likely involve caching the full path used by
the various open() syscalls for the life of the given fd and then
doing some rather painful string comparisons on each file i/o syscall
- no thank you ;)

-- 
paul moore
www.paul-moore.com