On Thu, Nov 7, 2019 at 1:07 PM Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > On 11/7/19 12:48 PM, Paul Moore wrote: > > On Thu, Oct 31, 2019 at 10:01 AM Stephen Smalley <sds@xxxxxxxxxxxxx> > wrote: > > That is an interesting question: do we consider dmesg output to be > > part of the stable kernel API? My hunch would be "no", as I've seen > > things change quite a bit there over the years, but IANL (I Am Not > > Linus). However, that said, logging a reason string via audit seems > > like a good idea (especially since there is presently a many-to-one > > mapping between reasons and the SELinux permission). Further, while > > the audit field name is part of the kernel API, the value is much more > > open. > > Ok, any preferences on the audit field name or should we just create one > and cc linux-audit on the next RFC? lockdown_reason=? Definitely CC linux-audit as I expect Steve will want to have his say. FWIW, "lockdown_reason" seems reasonable to me. > >> I also wasn't sure about the pr_warn() above. If we reach it, it is > >> effectively a kernel bug. We could mirror what the lockdown module does > >> in lockdown_is_locked_down(), i.e. use WARN() instead. Of course, the > >> SELinux hook won't even be reached in this case if the lockdown module > >> is enabled, but the lockdown module could be disabled so I guess we need > >> to check it too. > > > > Since this seems security relevant, I wonder if we should be using SELINUX_ERR? > > The benefit of a WARN() is that it will give us a stack trace showing > the offending caller in the kernel, which would be useful since it would > be a buggy caller passing an invalid lockdown reason (LOCKDOWN_NONE or > >= LOCKDOWN_CONFIDENTIALITY_MAX). pr_warn() or audit_log() won't give > us that info. We could do both of course. It's a balance between development needs and freaking out administrators (although perhaps rightly so). I also worry a bit that WARN can be disabled at build time so having something like SELINUX_ERR could be a good fallback, assuming we did both. -- paul moore www.paul-moore.com
