Re: [PATCH 1/2] audit: remove redundant data_len check

2022-06-07 Thread Paul Moore
On Sun, May 15, 2022 at 7:35 PM Paul Moore  wrote:
>
> On Sun, May 15, 2022 at 3:31 AM Shreenidhi Shedi  wrote:
> >
> > data_len is already getting checked if it's less than 2 earlier in this
> > function.
> >
> > Signed-off-by: Shreenidhi Shedi 
> > ---
> >  kernel/audit.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
>
> Thanks, this patch looks okay, but since we are already at v5.18-rc7
> this patch will have to wait until after the upcoming merge window as
> it isn't a critical bug fix.

... and it's now merged into audit/next, thanks!

-- 
paul-moore.com

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



Re: Be careful with rules

2022-06-07 Thread Lenny Bruzenak



On 6/7/22 09:14, Paul Moore wrote:

On Tue, Jun 7, 2022 at 11:02 AM Steve Grubb  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  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



Re: Be careful with rules

2022-06-07 Thread Paul Moore
On Tue, Jun 7, 2022 at 11:02 AM Steve Grubb  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  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



Re: Be careful with rules

2022-06-07 Thread Steve Grubb
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  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



Re: Be careful with rules

2022-06-07 Thread Paul Moore
On Mon, Jun 6, 2022 at 7:10 PM Lenny Bruzenak  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