On Mon, Aug 8, 2022 at 10:49 AM Ondrej Mosnacek <omosnace@xxxxxxxxxx> wrote: > > When debugging SELinux denials, it is often helpful to know which part > of kernel code triggered the denial. Thus, this patch adds a new > /sys/fs/selinux/warn_on_audited flag that, when set to 1, will cause any > audited AVC event to log a WARNING to the kernel console, which > naturally comes with a kernel stack trace. > > While the same can be achieved via the "avc:selinux_audited" kernel > tracepoint and the perf tool, that approach has several practical > disadvantages: > 1. It requires perf to be installed on the machine. > 2. It requires kernel debug symbols to be available when decoding the > stack trace. > 3. It requires a perf process to be running in the background. > 4. The stack traces can only be obtained at the end, after the perf > process is terminated, not live during the capture. (Though this may > be solved by writing a custom tool on top of libtraceevent.) > > Thus, providing a simple native knob for this in selinuxfs is still > valuable. > > The warn_on_audited flag is always set to 0 on boot and is expected to > be set to 1 only temporarily by system administrator in order to debug > SELinux denials. It is not intended to be used on production systems. > > Signed-off-by: Ondrej Mosnacek <omosnace@xxxxxxxxxx> > --- > security/selinux/avc.c | 6 +++ > security/selinux/ima.c | 11 +++++- > security/selinux/include/security.h | 11 ++++++ > security/selinux/selinuxfs.c | 61 +++++++++++++++++++++++++++++ > 4 files changed, 88 insertions(+), 1 deletion(-) I'm sorry, but I'm not going to merge this. At least not now. In general I don't like using WARN/WARN_ON/etc. for this; I believe their use should be limited for rather serious kernel issues and not as a developer's debugging tool. I also don't like duplicating the tracepoint functionality. I understand there are hurdles to using perf on a system, but I would much rather see work go into fixing that than duplicating its functionality -- paul-moore.com
