On 09/05/17 16:39, Paul Moore wrote:
On Mon, Sep 4, 2017 at 4:27 AM, Vegard Nossum <[email protected]> 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 <[email protected]>
---
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
--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit
