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

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

[Mateusz Piotrowski]

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.

My questions are:
1. Is this regex valid and up-to-date? Or is it an outdated rule which doesn't apply anymore?
2. Could you suggest me where to look to see how those arguments to the execve syscall are handled?
3. Could you post an example of a record with a field which fits the regex (assuming the regex is valid)?

Cheers!

-Mateusz

[1]: https://github.com/linux-audit/audit-documentation/blob/master/specs/fields/field-dictionary.csv#L3
[2]: https://www.redhat.com/archives/linux-audit/2012-October/msg00090.html

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

[Steve Grubb]

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. 

Here's one reference:
https://www.redhat.com/archives/linux-audit/2007-October/msg00015.html


> My questions are:
> 1. Is this regex valid and up-to-date? Or is it an outdated rule which
> doesn't apply anymore? 

Possibly. But try to generate it and see.

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

> 3. Could you post an example of a record with a field which fits the regex
> (assuming the regex is valid)?

The archive link above explains what was going to be added. Offhand I don't 
have one of these laying around in my logs. This test might create one for 
you:

https://github.com/linux-audit/audit-testsuite/tree/master/tests/exec_execve

-Steve


> [1]:
> https://github.com/linux-audit/audit-documentation/blob/master/specs/fields
> /field-dictionary.csv#L3 [2]:
> https://www.redhat.com/archives/linux-audit/2012-October/msg00090.html
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

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

[Mateusz Piotrowski]

On 01 Aug 2016, at 16:46, Steve Grubb <sgrubb@redhat.com> wrote:
> 
> On Monday, August 1, 2016 12:16:30 AM EDT Mateusz Piotrowski wrote:
>> 
>> 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. 
> 
> Here's one reference:
> https://www.redhat.com/archives/linux-audit/2007-October/msg00015.html

Thanks.

>> My questions are:
>> 1. Is this regex valid and up-to-date? Or is it an outdated rule which
>> doesn't apply anymore? 
> 
> Possibly. But try to generate it and see.

Sure, I'll notify you if I manage to get one.

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

Yeah, that's what I was trying to find - how this regex is handled in auparse/interpret.c[2]. 
We can see how "a0" is handled for example[3] but I couldn't find anything about "a4[foo]".

>> 3. Could you post an example of a record with a field which fits the regex
>> (assuming the regex is valid)?
> 
> The archive link above explains what was going to be added. Offhand I don't 
> have one of these laying around in my logs. This test might create one for 
> you:
> 
> https://github.com/linux-audit/audit-testsuite/tree/master/tests/exec_execve

Thanks a lot.

>> [1]:
>> https://github.com/linux-audit/audit-documentation/blob/master/specs/fields
>> /field-dictionary.csv#L3 [2]:
>> https://www.redhat.com/archives/linux-audit/2012-October/msg00090.html

Cheers,

-m

[2]: https://github.com/linux-audit/audit-userspace/blob/master/auparse/interpret.c
[3]: https://github.com/linux-audit/audit-userspace/blob/master/auparse/interpret.c#L2805

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

[Paul Moore]

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

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

[Mateusz Piotrowski]

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

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

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

[Paul Moore]

On Mon, Aug 8, 2016 at 8:01 AM, Mateusz Piotrowski <0mp@freebsd.org> wrote:
> On 07 Aug 2016, at 20:51, Paul Moore <paul@paul-moore.com> wrote:
>
>> On Mon, Aug 1, 2016 at 10:46 AM, Steve Grubb <sgrubb@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

That is correct, assuming that the a4_len and a4[0] field occur in one
record, a[1] in a second, a[2] in a third, and so on.  You should
never see aX[n] and aX[n+1] in a single record, if you, it's a bug :)

> 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 len field gets used for a lot of things, but for understanding
individual argument lengths, you should pay attention to the aX_len
field (when present).

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

When in doubt, Google is generally very helpful, but here is a link:

 * https://www.kernel.org

-- 
paul moore
www.paul-moore.com