Be careful with rules

Lenny Bruzenak lenny at magitekltd.com
Tue Jun 7 16:35:55 UTC 2022


On 6/7/22 09:14, Paul Moore wrote:
> On Tue, Jun 7, 2022 at 11:02 AM Steve Grubb <sgrubb at 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 at 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



More information about the Linux-audit mailing list