* 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