Re: Can AUDIT_LIST_RULES causes kthreadd-spam?

[Rinat Gadelshin <rgadelsh@gmail.com>]

On 04.05.2023 00:27, Paul Moore wrote:
> On Wed, May 3, 2023 at 5:14 PM Rinat Gadelshin <rgadelsh@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@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@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?

--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit