[PATCH] audit: add task history record
Tetsuo Handa
penguin-kernel at I-love.SAKURA.ne.jp
Sat Aug 12 10:08:09 UTC 2023
On 2023/08/12 2:50, Richard Guy Briggs wrote:
> On 2023-08-11 19:58, Tetsuo Handa wrote:
>> When an unexpected system event occurs, the administrator may want to
>> identify which application triggered the event. For example, unexpected
>> process termination is still a real concern enough to write articles
>> like https://access.redhat.com/solutions/165993 .
>>
>> This patch adds a record which emits TOMOYO-like task history information
>> into the audit logs for better understanding of unexpected system events.
>>
>> type=UNKNOWN[1340] msg=audit(1691750738.271:108): history="name=swapper/0;pid=1;start=20230811194329=>name=init;pid=1;start=20230811194343=>name=systemd;pid=1;start=20230811194439=>name=sshd;pid=3660;start=20230811104504=>name=sshd;pid=3767;start=20230811104535"
>>
>> To be able to avoid bloating audit log files due to this information, this
>> patch uses audit_history= kernel command line parameter that controls max
>> length of history in bytes (default is 1024, and setting to 0 disables
>> recording and emitting).
>
> The record length limit is just below 8k. Is it reasonable to set the
> default at 4k and cap it around 7.5k to be safe?
Below will do it. (I though default at 0 might be better...)
+static unsigned int audit_history_size __ro_after_init = 4096;
+char init_task_audit_history[7680];
+static int __init audit_history_setup(char *str)
+{
+ unsigned int size;
+
+ if (kstrtouint(str, 10, &size))
+ return -EINVAL;
+ if (size > sizeof(init_task_audit_history))
+ size = sizeof(init_task_audit_history);
+ audit_history_size = size;
+ return 0;
+}
>
> Is proctitle also useful here? It contains the full command line, but
> is influencible by userspace.
Full pathname is max 4096 bytes. But full command line effectively has no
limit, which might become very long. Shouldn't full command line arguments
be retrieved from execve()'s argv[] record? Since this history information
includes timestamp of execve(), also recording execve() requests will allow
administrators to find the full command line.
>> Unlike execve()'s argv record, records in this history information is
>> emitted as one string in order to reduce bloat of the audit log files.
>> This information can be split into an array using => as the tokenizer.
>> But don't expect that you can compare array elements throughout the whole
>> audit logs by splitting into an array, for old records get removed from
>> history when history became too long to append the newest record. This
>> history information is meant to be interpreted by humans rather than be
>> analyzed by programs.
>
> You say this isn't intended to be analysed by programs, but we all know
> it will inevitably be attempted... Would any of the descendants of
> audit_log_untrustedstring() be of use, in particular
> audit_string_contains_control()
I couldn't catch what you are suggesting. Are you suggesting something like
type=UNKNOWN[1340] msg=audit(1691750738.271:108):
n[$n]="swapper/0" n[$n+1]="init" n[$n+2]="systemd" n[$n+3]="sshd" n[$n+4]="sshd"
p[$n]=1 p[$n+1]=1 p[$n+2]=1 p[$n+3]=3660 p[$n+4]=3767
s[$n]=20230811194329 s[$n+1]=20230811194343 s[$n+2]=20230811194439 s[$n+3]=20230811104504 s[$n+4]=20230811104535
so that value for n[$n] is escaped only when control characters are in use?
More information about the Linux-security-module-archive
mailing list