Re: Question about the a[[:digit:]+]\[.*\] fields
On Mon, Aug 1, 2016 at 10:46 AM, Steve Grubb <sgrubb(a)redhat.com> wrote:
On Monday, August 1, 2016 12:16:30 AM EDT Mateusz Piotrowski wrote:
> Hello,
>
> According to the field dictionary[1] there are fields which names are
> defined by the following regex: "a[[:digit:]+]\[.*\]".
>
> I was able to find examples of fields like "a4" and "a5" (see
[2]) but it
> doesn't fit the regex which seems to require a pair of square brackets (so
> "a4" should be "a4[]" or "a4[foo]"). I couldn't
find any reference in the
> Linux Audit source code.
I think you have to have aurguments that are larger than the audit record
limit and so many arguments that you have multiple execve records to contain
them all.
Sorry for the delay in responding, but yes, that is mostly correct.
If there is an argument that spills across the boundary of a single
EXECVE record, either due to an exceptionally large size, or little
room remaining in the existing record, an argument length field is
added to the record (a2_len=x) and the argument value is spilt and
indexed (a2[0]=x ... a[n]=x).
The relevant code in the kernel just changed over the past few weeks
to correct some problems, so there are some subtle differences between
old code and what you will find in Linus' tree at the moment, but none
of those changes should affect the regex you've described.
> My questions are:
> 1. Is this regex valid and up-to-date? Or is it an outdated rule which
> doesn't apply anymore?
It is correct if the argument spills across a single EXECVE record
boundary, but since the index (the number between the square brackets)
is not optional it would fail for the more common, single EXECVE
record case. You could also argue that the string match inside the
square brackets should only match on a string of digits, but
technically what is there does work.
> 2. Could you suggest me where to look to see how those arguments
to the
> execve syscall are handled?
Handled where? Kernel? Userspace doesn't do much with any execve argument
except decode it.
The kernel generates the EXECVE record in
kernel/auditsc.c:audit_log_execve_info() and you can find a test for
for the EXECVE record in the audit-testsuite (exec_execve).
* https://github.com/linux-audit/audit-testsuite
--
paul moore
www.paul-moore.com