On Tue, Aug 16, 2022 at 5:31 AM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > 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 OK, I'm not going to argue against that, but I had to at least try :) -- Ondrej Mosnacek Senior Software Engineer, Linux Security - SELinux kernel Red Hat, Inc.