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&gt; > 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&gt; >> --- >> 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.

From what I can see you are asking upstream to make accommodations for