Question about the a[[:digit:]+]\[.*\] fields

[Mateusz Piotrowski]

On 07 Aug 2016, at 20:51, Paul Moore <paul at paul-moore.com> wrote:

> On Mon, Aug 1, 2016 at 10:46 AM, Steve Grubb <sgrubb at 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).

Could you please correct me if I am wrong? From what I understand 
(based on kernel/auditsc.c:audit_log_single_execve_arg()[2]) a 
correct set of fields could possibly look like this:

    a4_len=4 a4[0]=a a4[1]=n a4[2]=i a4[3]=a

as long as there are no unprintable control ascii characters (otherwise
the a4_len field's value would be 8 as every character is printed in hex).

How about the "a[[:digit:]+]_len" fields (for example a4_len)? 
Are they synonymous with the len field[1]?

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

I'd appreciate if you could point me to a web server where I can download 
the kernel's source code you write about. I do not deal with Linux Kernel 
source code on daily basis and search engines don't produce obvious results.

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

OK, I get it. Thank you.

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

Thanks. It clarifies a lot and will help me to advance with my GSoC project[3].

Cheers!

-m

[1]: https://github.com/linux-audit/audit-documentation/blob/master/specs/fields/field-dictionary.csv#L95
[2]: http://lxr.free-electrons.com/source/kernel/auditsc.c#L1095
[3]: https://wiki.freebsd.org/SummerOfCode2016/NonBSMtoBSMConversionTools