5:16 p.m.
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/fiel...
[2]: https://www.redhat.com/archives/linux-audit/2012-October/msg00090.html
9:46 a.m.
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
10:13 a.m.
On 01 Aug 2016, at 16:46, Steve Grubb <sgrubb(a)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/interp...
[3]: https://github.com/linux-audit/audit-userspace/blob/master/auparse/interp...
1:51 p.m.
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
7:01 a.m.
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
8:03 a.m.
On Mon, Aug 8, 2016 at 8:01 AM, Mateusz Piotrowski <0mp(a)freebsd.org> wrote:
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
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
3057
days inactive
3065
days old
linux-audit@lists.linux-audit.osci.io
5 comments
3 participants
participants (3)
-
Mateusz Piotrowski -
Paul Moore -
Steve Grubb