Re: Linux Audit userspace query

Re: Linux Audit userspace query

[Ondrej Mosnáček]

Hello Ali,

pi 26. 7. 2019 o 15:00 Ali Ahad <20100284@lums.edu.pk> napísal(a):
> Dear Ondrej,
>
>                     I am computer science student currently enrolled in my senior year at Lahore University of Management Sciences (LUMS) , Pakistan . I am writing this email in regards to a problem that I am facing while working on the repository "Linux Audit userspace".
>
>                    The summer research project I have been working on involves modifying and customizing the linux audit userspace such that I can customize the AUDIT_ARGS (a0,a1,a2 etc) of the write system calls being recorded. I have been looking the repository for days now and am unable to figure out the source of where the syscalls or any other events are being recorded.

I'm not sure what exactly you are trying to achieve, but the audit
records are not generated in the userspace programs, but in the
kernel. The userspace code (auditd) only receives them, writes them
into log files and optionally passes them on to other programs. There
are also utilities for parsing (libauparse, ...) and searching the
records (ausearch, ...).

>
>                  Basically, I am unable to figure out where an audit_event is being populated with the relevant data such as the audit_args (a0,a1,a2) so that I can change and play around with the arguments that  are being recorded and populated at the source.

Again, to change the way values are being recorded into the record,
you'd need to modify the kernel.

>
>                   Kindly let me know if you can slightly guide me in this regard. I would be really grateful. Also kindly let me know of the feasibility of the problem. So basically the argument a1 of the write syscall records the pointer to a buffer. Is it possible to store the dereferenced complete buffer as the argument instead?

It is technically possible, again at the kernel level. Obviously we
don't do that currently, since to post-process the arguments you'd
need to do specific stuff for each specific syscall, which would lead
to excessive logging, challenges with record format, keeping the code
in sync with all the syscalls being supported in the kernel, etc...
For logging extended information about what is happening in each
syscall, we usually use separate records with specific type and fields
that are associated to the syscall record based on record ID.

I'm adding the linux-audit mailing list to Cc - that is the official
place to discuss questions about Linux audit subsystem and the
associated userspace tools. You are likely to get a reply from people
much more involved and educated in audit than me :)

>
>                  Thanks in anticipation. Really looking forward to hearing back from you.
>
> Best,
> Ali Ahad,
> Lahore University of Management Sciences (LUMS)

Cheers and good luck with your project!

Ondrej Mosnacek

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

Re: Linux Audit userspace query

[Steve Grubb]

On Wednesday, July 31, 2019 7:06:53 AM EDT Ondrej Mosnáček wrote:
> > Basically, I am unable to figure out where an audit_event is being
> > populated with the relevant data such as the audit_args (a0,a1,a2) so
> > that I can change and play around with the arguments that  are being
> > recorded and populated at the source.
>
> Again, to change the way values are being recorded into the record,
> you'd need to modify the kernel.

Right. Everything comes from the kernel. Audit userspace just stores it to 
disk and that is why you don't see any code dealing with the args.
 
> > Kindly let me know if you can slightly guide me in this regard. I would
> > be really grateful. Also kindly let me know of the feasibility of the
> > problem. 

You would need to learn to build, modify, and debug kernels.

> > So basically the argument a1 of the write syscall records the
> > pointer to a buffer. Is it possible to store the dereferenced complete
> > buffer as the argument instead?

Writes can be huge and could contain sequences designed to trick parsers. 
That means it would need to be encoded which doubles the size of the write 
data being collected. Also, I think there are file systems that are 
journalling meaning that their metadata contains what the changes are in case 
it has to recover. That might be another avenue to investigate.

-Steve



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