[PATCH] audit: reserve a numerical code for AUDIT_ANOM_PATCHED

[Paul Moore]

On Wed, Sep 6, 2017 at 9:20 AM, Vegard Nossum <vegard.nossum at oracle.com> wrote:
> On 09/05/17 16:39, Paul Moore wrote:
>>
>> On Mon, Sep 4, 2017 at 4:27 AM, Vegard Nossum <vegard.nossum at 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 at 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