Can AUDIT_LIST_RULES causes kthreadd-spam?
Rinat Gadelshin
rgadelsh at gmail.com
Wed May 3 22:12:20 UTC 2023
On 04.05.2023 00:27, Paul Moore wrote:
> On Wed, May 3, 2023 at 5:14 PM Rinat Gadelshin <rgadelsh at gmail.com> wrote:
>> Hello there =)
>>
>> My name is Rinat.
>> I'm a newbie here (at Linux kernel developer community).
>>
>> My current job is to work with audit subsystem on different
>> versions of Linux (and different kernel versions from 3.10 to the latest)
>> with and without auditd.
>>
>> My program works behalf of root account and uses netlink
>> (unicast or multicast depends of the kernel's version)
>> to communicate with audit subsystem of the kernel.
>>
>> If actual audit rule list has been changed
>> then my program should restore the configured audit rule list.
>>
>> To do it the program periodically (with 60 seconds interval)
>> requests the actual rule list be sending AUDIT_LIST_RULES.
>>
>> All rules are receiving perfectly.
>>
>> But I've noticed that there are many (2K+ for 5 minutes test)
>> kthreadd process have been spawned after that request
>> (I've stubbed the poll code and compare logs).
> Hi Rinat,
>
> First, a quick note that audit discussions involving the upstream
> Linux Kernel have moved to the audit at vger.kernel.org list (CC'd),
> please direct future emails there.
>
> Can you be more specific about the kernel threads you are seeing, are
> you seeing multiple "kauditd" threads?
>
> % ps -fC kauditd
> UID PID PPID C STIME TTY TIME CMD
> root 89 2 0 Apr28 ? 00:00:00 [kauditd]
>
>> Please, can you point me, what can I do to avoid this kthreadd-spam.
>>
>> Thank you.
>>
>> Best regards
>> Rinath
Hi Paul,
Thank you for your quick answer.
I swear to copy my future questions about audit subsystem to
audit at vger.kernel.org =)
My logs don't provide lot of info about nature of the kthreadds.
(I hadn't written the log system).
I have something like this:
...pid: 2, uniquePid: 000082d800000002, fileName: kthreadd, lcFileName:
kthreadd, name: kthreadd, commandLine: Skipped, lcCommandLine: Skipped,
sessionId: 0, isRemote: 0, syscallName: fork, uid: 4294967295, gid:
4294967295, euid: 4294967295, egid: 4294967295, logonSessionUid: -1,
logonSessionUsername: Skipped, logonSessionRemoteHost: , exeOwnerUid: 0,
exeOwnerGid: 0, exeMode: 0, exeInode: 0, exeCapsVersion: ,
exeCapsRootId: , exeCapsEffective: , exeCapsPermitted: ,
exeCapsInheritable: , dstPid: 106574, dstTid: 0, dstUniquePid:
000083b10001a04e, requestId: 2684354949, startTime: 01d97d1fb24aa38e,
hash: 00000000000000000000000000000000, cwd: , flags: 00000011,
processState: 3, int: 0, type: 00000000..
And such events occurred 1208 times when AUDIT_LIST_RULES is sending.
The test has lasted 2 minutes.
The same test in which the request was disabled produced only 122 such
records.
It was the only difference between the tests.
As I can see it was a fork syscall of kthreadd.
Are there any debug options for the kernel that I can set, rebuild the
kernel, re-run the test and clarify the situation?
More information about the Linux-audit
mailing list