On Wed, Sep 6, 2017 at 9:20 AM, Vegard Nossum <vegard.nos...@oracle.com> wrote: > On 09/05/17 16:39, Paul Moore wrote: >> >> On Mon, Sep 4, 2017 at 4:27 AM, Vegard Nossum <vegard.nos...@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.nos...@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.
>From what I can see you are asking upstream to make accommodations for a patchset that has not been merged in several years, nor are there any plans of pushing this functionality forward upstream, yes? If that is the case, the answer remains "no". I understand your maintenance concern (I also wear a distro "hat" for my day job), but it is well established that distributions which merge out-of-tree kernel code must also bear the maintenance responsibility of that code. Upstream can not be responsible for out-of-tree and distribution specific kernel changes. If you want upstream to reserve a audit record number you will need to get your patchset accepted upstream. -- paul moore www.paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
