syscalls

[Debora Velarde]

Hi Chris,

Either number or name are okay.
      -a entry,always -S unlink
      -a entry,always -S chown
should also work.

-debbie

linux-audit-bounces at redhat.com wrote on 05/04/2005 12:39:57 PM:

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

> --
> Linux-audit mailing list
> Linux-audit at redhat.com
> http://www.redhat.com/mailman/listinfo/linux-audit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20050504/52f370d8/attachment.htm>