11:15 a.m.
All,
We're working with Docker and podman, and I'm working on parsing the audit data we
get to flag prohibited and missing command options based on STIG guidelines. I normally
extract the proctitle from the raw auditd data , but these commands are very long with
sometimes 23 or more command line parameters , and I noticed that all of the auditd
proctitle data for the lengthier commands is being cut off at 128 characters.
I'm bringing this up for two reasons:
One, not everyone working with this data may realize that there seems to be a
character limit,
and second, if this is by chance a bug as opposed to intentional, then I'm
hoping we can get a fix cooking for it?
In the meantime, I may be able to work around this by piecing together the full command
from the "a#= " fields, but it would be much easier if proctitle wasn't cut
off after 128 chars.
Thanks, any info you can share would be much appreciated,
Karen Wieprecht
9:38 p.m.
On 2023/09/16 1:15, Wieprecht, Karen M. wrote:
All,
We're working with Docker and podman, and I'm working on parsing the audit data
we get to flag prohibited and missing command options based on STIG guidelines.
I normally extract the proctitle from the raw auditd data , but these commands
are very long with sometimes 23 or more command line parameters , and I noticed
that all of the auditd proctitle data for the lengthier commands is being cut off
at 128 characters.
This limitation is intentional
( https://elixir.bootlin.com/linux/v6.6-rc2/source/kernel/auditsc.c#L81 ).
Since each argv[]/envp[] value passed to execve() can go up to 128KB
( https://elixir.bootlin.com/linux/v6.6-rc2/source/include/uapi/linux/binfm... )
and number of arguments is effectively unlimited
( https://elixir.bootlin.com/linux/v6.6-rc2/source/include/uapi/linux/binfm... ),
trying to audit full command line can exhaust storage.
I'm bringing this up for two reasons:
One, not everyone working with this data may realize that there seems to be
a character limit,
and second, if this is by chance a bug as opposed to intentional, then I'm
hoping we can get a fix cooking for it?
In the meantime, I may be able to work around this by piecing together the full
command from the "a#= " fields, but it would be much easier if proctitle
wasn't
cut off after 128 chars.
If you can use an out-of-tree LSM, you can use execute_handler feature available in
TOMOYO and CaitSith, which replaces any execve() request with a specific execve()
request in order to allow userspace to examine and audit (and optionally sanitize)
full command line before executing the originally requested program.
https://tomoyo.osdn.jp/1.8/policy-specification/domain-policy-syntax.html...
https://en.osdn.net/projects/tomoyo/scm/svn/blobs/head/trunk/1.8.x/ccs-to...
If you think execute_handler feature is helpful for you, I can make a dedicated LSM
which implements only execute_handler feature.
Thanks, any info you can share would be much appreciated,
Karen Wieprecht
6:32 p.m.
On Friday, September 15, 2023 12:15:12 PM EDT Wieprecht, Karen M. wrote:
We're working with Docker and podman, and I'm working on
parsing the audit
data we get to flag prohibited and missing command options based on STIG
guidelines. I normally extract the proctitle from the raw auditd data ,
but these commands are very long with sometimes 23 or more command line
parameters , and I noticed that all of the auditd proctitle data for the
lengthier commands is being cut off at 128 characters.
The proctitle event commit message explains why it was created:
https://listman.redhat.com/archives/linux-audit/2014-February/008778.html
The comm field is only 16 characters long. So, it tries to capture the first
128 bytes so that at least android comm fields can be deduced since they are
almost always larger than 16 bytes.
I'm bringing this up for two reasons:
One, not everyone working with this data may realize that there seems
to be a character limit, and second, if this is by chance a bug as opposed
to intentional, then I'm hoping we can get a fix cooking for it?
The record that contains all of the command line is the execve record. It has
all parameters even if it's 10,000. So, you may want to try auditing by exec
of specific applications to get everything.
Also, as mentioned in the commit, proctitle is based off of comm. This can be
controlled by user space to misdirect attention by spoof the program name.
In the meantime, I may be able to work around this by piecing
together the
full command from the "a#= " fields, but it would be much easier if
proctitle wasn't cut off after 128 chars.
Thanks, any info you can share would be much appreciated,
This was intentional. There was a long discussion of this in January and
February of 2014 if you want more background.
-Steve
1:11 p.m.
New subject: [EXT] Re: 128 Character limit on proctitle field?
Spotted the EXECVE arguments as well, I'll definitely need to look here since the
proctitle is limited to 128 chars. Appreciate the feedback and info, thanks!
-----Original Message-----
From: Steve Grubb <sgrubb(a)redhat.com>
Sent: Tuesday, September 19, 2023 7:32 PM
To: linux-audit(a)redhat.com
Cc: Wieprecht, Karen M. <Karen.Wieprecht(a)jhuapl.edu>
Subject: [EXT] Re: 128 Character limit on proctitle field?
APL external email warning: Verify sender sgrubb(a)redhat.com before clicking links or
attachments
On Friday, September 15, 2023 12:15:12 PM EDT Wieprecht, Karen M. wrote:
We're working with Docker and podman, and I'm working on
parsing the
audit data we get to flag prohibited and missing command options based on STIG
guidelines. I normally extract the proctitle from the raw auditd data ,
but these commands are very long with sometimes 23 or more command
line parameters , and I noticed that all of the auditd proctitle data
for the lengthier commands is being cut off at 128 characters.
The proctitle event commit message explains why it was created:
https://listman.redhat.com/archives/linux-audit/2014-February/008778.html
The comm field is only 16 characters long. So, it tries to capture the first
128 bytes so that at least android comm fields can be deduced since they are almost always
larger than 16 bytes.
I'm bringing this up for two reasons:
One, not everyone working with this data may realize that there
seems to be a character limit, and second, if this is by chance a bug
as opposed to intentional, then I'm hoping we can get a fix cooking for it?
The record that contains all of the command line is the execve record. It has all
parameters even if it's 10,000. So, you may want to try auditing by exec of specific
applications to get everything.
Also, as mentioned in the commit, proctitle is based off of comm. This can be controlled
by user space to misdirect attention by spoof the program name.
In the meantime, I may be able to work around this by piecing
together the full command from the "a#= " fields, but it would be
much easier if proctitle wasn't cut off after 128 chars.
Thanks, any info you can share would be much appreciated,
This was intentional. There was a long discussion of this in January and February of 2014
if you want more background.
-Steve
458
days inactive
463
days old
linux-audit@lists.linux-audit.osci.io
3 comments
3 participants
participants (3)
-
Steve Grubb -
Tetsuo Handa -
Wieprecht, Karen M.