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=?
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.
