Re: Be careful with rules

From: Lenny Bruzenak <lenny@magitekltd.com>
To: Paul Moore <paul@paul-moore.com>, Steve Grubb <sgrubb@redhat.com>
Cc: linux-audit@redhat.com
Subject: Re: Be careful with rules
Date: Tue, 7 Jun 2022 10:35:55 -0600	[thread overview]
Message-ID: <250b3286-df7f-ea75-65dd-6af6b7d7ebbe@magitekltd.com> (raw)
In-Reply-To: <CAHC9VhSiijSd=D8nX1G6z1DHmS0GDu04NYiGmnb_QGRzsqcqXg@mail.gmail.com>

On 6/7/22 09:14, Paul Moore wrote:
> On Tue, Jun 7, 2022 at 11:02 AM Steve Grubb <sgrubb@redhat.com> wrote:
>> On Tuesday, June 7, 2022 9:42:06 AM EDT Paul Moore wrote:
>>> On Mon, Jun 6, 2022 at 7:10 PM Lenny Bruzenak <lenny@magitekltd.com> wrote:
>>>> I've been told that it is not a potential security problem, and not
>>>> subject to change in the (current) kernel.
>>> I'm that little birdy that Lenny was talking to off-list so I figured
>>> I would add a quick comment here :)
>>>
>>> As a reminder, elevated privilege is needed to both add/remove/modify
>>> audit rules as well as the loaded SELinux policy (affecting the
>>> validity of the relevant security labels).  Also, as Lenny already
>>> mentioned, if an invalid security label is used, the kernel will
>>> notify the admin via the kernel log.
>> Wouldn't it be better if the kernel knew the rule was invalid to return
>> EINVAL so that rule loading stops or becomes an error return from auditctl? A
>> long time ago, there was no way from user space to check a type or a role or
>> an selinux user for validity. Can that be done now? Is there an API for it?
> We don't want to change how the kernel responds to userspace input
> unless we have no (good) choice.  According to the git log, the kernel
> has behaved like this for almost 20 years, this is not something we
> want to change, especially given that we already need to trust the
> administrator to configure the system correctly.
>
> As I told Lenny earlier, I agree that the existing behavior is a bit
> silly, but it's not something we can really change at this point with
> the current API.  Future API changes will make things like this much
> easier (hopefully I'll have more to share on this later this year).

For anyone who has audit rules that include type filters for subject or object (subj_user, subj_role, subj_type, subj_sen, subj_clr, obj_ser, obj_role, obj_type, obj_lev_low, or obj_lev_high), I recommend doing this ASAP to see if you are affected:

# dmesg | grep "LSM.*invalid"

If you see this, you are affected. No OpenSCAP scans or other userspace security validators will catch this AFAIK.

LCB

-- 
Lenny Bruzenak
MagitekLTD

--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit