Linux-audit Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Be careful with rules
@ 2022-06-06 23:09 Lenny Bruzenak
  2022-06-07 13:42 ` Paul Moore
  0 siblings, 1 reply; 5+ messages in thread
From: Lenny Bruzenak @ 2022-06-06 23:09 UTC (permalink / raw)
  To: linux-audit


[-- Attachment #1.1: Type: text/plain, Size: 2494 bytes --]

All,

I came across some strange behavior recently on SElinux with audit 
rules. It has been in the kernel a long time. I thought it was worth 
sharing.

If you specify a non-existent type in a audit syscall filter rule, the 
kernel will accept it and advertise it as being valid, but in essence it 
invalidates all audits of those syscalls.

For example, starting with this common rule:

# auditctl -a exit,always -F arch=b64 -S mount,umount2 -k MNT

# auditctl -l -k MNT

-a always,exit -F arch=b64 -S mount,umount2 -F key=MNT


All good. Try mounting and unmounting, you'll get audited results with:

# ausearch -i -k MNT


Now, delete that rule (assuming you didn't already have the rules loaded 
with the "-e 2"  which locks the rules),

# auditctl -d exit,always -F arch=b64 -S mount,umount2 -k MNT

and you will not see any more mount/umount syscall events. Fine.


But, change the rule to use a non-existent type value, such as:

# auditctl -a exit,always -F arch=b64 -S mount,umount2 -F 
subj_type!=e_snowden_t -k MNT

and the return code is valid, plus it appears all is well:

# auditctl -l -k MNT

-a always,exit -F arch=b64 -S mount,umount2-F subj_type!=e_snowden_t -F 
key=MNT


So, being the naive user that I am, I assume that this rule is in 
effect, valid, and means, "Audit all mount/umount2 syscalls except those 
of subject type e_snowden_t and mark them with the MNT key".

But that isn't what happens.

Instead, what happens is that:

 1. A message gets written into the dmesg buffer saying "[<timestamp>]
    audit rule for LSM 'e_snowden_t' is invalid".
 2. All subsequent mount/umount syscalls are now NOT audited, regardless
    of the types. There is essentially no mount/umount2 rule valid at
    this point, regardless of the "auditctl -l" answer.


I verified that in the current github code this is accurate for (1) 
above, then asked about it:

https://github.com/linux-audit/audit-kernel/blame/69bb189e81e081a4e92e8fa4cbcc9fd407252dc1/kernel/auditfilter.c#L531-L538


I've been told that it is not a potential security problem, and not 
subject to change in the (current) kernel.

I'm hoping that it may help someone else in being aware that:

  * You cannot trust what the kernel says WRT audit rules that specify
    type, and therefore
  * You need to be certain that you do not field a system having audit
    rules with a non-existent value in the field specifiers that deal
    with subject or object values.


Thx,

LCB


-- 
Lenny Bruzenak
MagitekLTD

[-- Attachment #1.2: Type: text/html, Size: 3547 bytes --]

[-- Attachment #2: Type: text/plain, Size: 107 bytes --]

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Be careful with rules
  2022-06-06 23:09 Be careful with rules Lenny Bruzenak
@ 2022-06-07 13:42 ` Paul Moore
  2022-06-07 15:02   ` Steve Grubb
  0 siblings, 1 reply; 5+ messages in thread
From: Paul Moore @ 2022-06-07 13:42 UTC (permalink / raw)
  To: Lenny Bruzenak; +Cc: linux-audit

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.

-- 
paul-moore.com

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Be careful with rules
  2022-06-07 13:42 ` Paul Moore
@ 2022-06-07 15:02   ` Steve Grubb
  2022-06-07 15:14     ` Paul Moore
  0 siblings, 1 reply; 5+ messages in thread
From: Steve Grubb @ 2022-06-07 15:02 UTC (permalink / raw)
  To: linux-audit, Paul Moore

Hello Paul,

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?

-Steve


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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Be careful with rules
  2022-06-07 15:02   ` Steve Grubb
@ 2022-06-07 15:14     ` Paul Moore
  2022-06-07 16:35       ` Lenny Bruzenak
  0 siblings, 1 reply; 5+ messages in thread
From: Paul Moore @ 2022-06-07 15:14 UTC (permalink / raw)
  To: Steve Grubb; +Cc: linux-audit

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).

-- 
paul-moore.com

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Be careful with rules
  2022-06-07 15:14     ` Paul Moore
@ 2022-06-07 16:35       ` Lenny Bruzenak
  0 siblings, 0 replies; 5+ messages in thread
From: Lenny Bruzenak @ 2022-06-07 16:35 UTC (permalink / raw)
  To: Paul Moore, Steve Grubb; +Cc: linux-audit


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


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2022-06-07 16:36 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-06-06 23:09 Be careful with rules Lenny Bruzenak
2022-06-07 13:42 ` Paul Moore
2022-06-07 15:02   ` Steve Grubb
2022-06-07 15:14     ` Paul Moore
2022-06-07 16:35       ` Lenny Bruzenak

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox