Re: [PATCH] audit: reserve a numerical code for AUDIT_ANOM_PATCHED
On 09/05/17 16:39, Paul Moore wrote:
On Mon, Sep 4, 2017 at 4:27 AM, Vegard Nossum
<vegard.nossum(a)oracle.com> wrote:
> A few years ago, I suggested a feature dubbed "known exploit detection".
> This feature defines an interface that allows kernel developers to add
> a tripwire for somebody who tries to exploit a known security hole in
> older versions of the kernel. See [1] for an article and the original
> discussion.
>
> [1]: https://lwn.net/Articles/577432/
>
> Due to the somewhat controversial nature of this feature, I never pushed
> very hard for it to go upstream. However, regardless of whether this code
> ever makes it upstream, it would still be useful to reserve a numerical
> code for the audit message in order to ensure that private deployments
> never conflicts with future upstream kernels.
>
> I hereby request the reservation of AUDIT_ANOM_PATCHED as code 1703. This
> message should be used when userspace makes a request which in previous
> (unpatched) versions of the kernel would have allowed the process to
> illicitly gain privileges (e.g. arbitrary code execution, etc.).
>
> Signed-off-by: Vegard Nossum <vegard.nossum(a)oracle.com>
> ---
> include/uapi/linux/audit.h | 1 +
> 1 file changed, 1 insertion(+)
In general I'm opposed to reserving audit message IDs for kernel code
that hasn't been accepted upstream and I don't yet see a compelling
reason to do so here.
Hi Paul,
I only submitted this patch to prevent a potential semantic conflict in
the future if mainline gains additional messages codes, which could
cause kernel/userspace binary incompatibilities across distros. We can
always effectively fork the protocol, but won't you agree that seems
more undesirable than adding a message code which remains unused in
mainline and otherwise has no maintenance overhead whatsoever? The
message itself is well-defined (and has no specific syntactic
requirements as far as we're concerned, but we can specify it in detail
if that's what you would prefer).
To be clear, what I'm trying to achieve here is to avoid a fragmentation
of the _protocol_ while still allowing us to make changes to the kernel
that nobody else wants to have upstream. It seems like an obvious
win-win to me.
Thanks,
Vegard