On Sat, Aug 19, 2023 at 3:09 AM Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> wrote: > On 2023/08/18 23:59, Paul Moore wrote: > > Except we are not talking SELinux or LSMs here, we are talking about > > audit and the audit subsystem is very different from the LSM layer. > > The LSM layer is designed to be pluggable with support for multiple > > individual LSMs, whereas the audit subsystem is designed to support a > > single audit implementation. It is my opinion that the audit patch > > you have proposed here does not provide an audit administrator with > > any new capabilities that they do not currently have as an option. > > Before explaining why an audit administrator cannot afford emulating > this patch, I explain what this patch will do. > > There are three system calls for managing a process: fork()/execve()/exit(). > > https://I-love.SAKURA.ne.jp/tomoyo/fork.gif > https://I-love.SAKURA.ne.jp/tomoyo/execve.gif > https://I-love.SAKURA.ne.jp/tomoyo/exit.gif > > As a result, history of a process can be represented as a tree, where the > root of the tree is the kernel thread which is started by the boot loader. > > https://I-love.SAKURA.ne.jp/tomoyo/railway.gif > > This fundamental mechanism cannot be changed as long as Linux remains as a > Unix-like OS. That is, adding this information will not cause what you call > "the support burden" ...
Any new functionality added to the kernel, especially user visible functionality or some sort of interface, adds a support burden. Nothing is "free". > > There are also concerns around field formatting, record length, etc., > > but those are secondary issues compared to the more important issue of > > redundant functionality. > > If someone tries to emulate this patch, we need to be able to trace all > fork()/execve()/exit() system calls. Or, the history tree will be broken. > > If an audit administrator tries to emulate this patch using system call > auditing functionality, we need to make sure that > > "auditctl -D" must not clear rules for tracing fork()/execve()/exit() > system calls. This is impossible because this change will break userspace > programs expecting that "auditctl -D" clears all rules. It's a good thing that 'audtictl -d ...' exists so that one can selectively delete audit rules from the kernel. If someone wants to preserve specific audit rules, that is the way to do it; 'auditctl -D' is a very coarse tool and not something that is likely very useful for users with strict auditing requirements. > Rules for tracing fork()/execve()/exit() system calls must be enabled > when the kernel thread which is started by the boot loader starts. > How can we embed such system call auditing rules into the kernel and > tell whether to enable these rules using the kernel command line options? I would boot the system with 'audit=1' on the kernel command line and ensure that your desired audit rules are loaded as early in the boot process as possible, before any long-running processes/daemons/logins are started. Honestly, that's simply a good best practice for anyone who cares about maintaining a proper audit log, independent of the specific use case here. > In order to avoid possibility of loosing fork()/execve()/exit() records, > auditd must not be stopped even temporarily. Who wants to enforce such > requirement in order to be able to obtain process history information? A silly amount of work has gone into ensuring that the audit subsystem in the kernel doesn't lose records when properly configured. If you haven't already, I would encourage you to read the auditctl(8) man page and look for the parameters that adjust the audit backlog configuration. -- paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
