Re: Question about the a[[:digit:]+]\[.*\] fields
On 07 Aug 2016, at 20:51, Paul Moore <paul(a)paul-moore.com> wrote:
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).
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/fiel...
[2]: http://lxr.free-electrons.com/source/kernel/auditsc.c#L1095
[3]: https://wiki.freebsd.org/SummerOfCode2016/NonBSMtoBSMConversionTools