syscalls

[Javier Godinez]

Thanks Chris,

I appreciate your responce, I am a bit new to this so please bear with
me, one more question. So If I wanted to log every time that a delete
is performed, then it would probably be better to do it by number
right, like this:

  -a entry,always -S 10
rather than this, right?
  -a entry,always -S unlink

and if I want to log every time chown is called I would do:
  -a entry,always -S 182

does this seem correct?

thanks, javier


On 5/4/05, Chris Wright <chrisw at osdl.org> wrote:
> * Javier Godinez (godinezj at gmail.com) wrote:
> > Do the supported system calls depend on what the kernel supports or do
> > they depend on what auditd supports? It seems to me that it would have
> > to depend on whatever the kernel wants to send to user space right? So
> > every syscall that we want to be audited would have to be fist
> > implemented in the kernel, am I getting this right? I was looking
> > through the auditd sources and I was not able to find a list of
> > supported syscalls.
> 
> There's a couple of things here.
> 
> The kernel side auditing system is hooked into the syscall mechanism.
> As such, it will pick up any syscall that's made from userspace (by
> number).  Whether it's implemented in the kernel or not, audit can see
> that it was attempted.
> 
> To filter the syscall (still in kernel), this can be done by number, so
> it's smth. that can be filtered.  And filters (set by userspace) can be
> identified by number or name.
> 
> In user space (specifically auditctl), there's the possbility for being
> out of date between kernel and userspace, but that's only for using
> syscall names (not numbers).  Anytime you expect auditctl to know the
> translation between a syscall name and number you'll have a potential
> issue if the kernel is implementing a new syscall that auditctl didn't
> know about.
> 
> thanks,
> -chris
>