From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ondrej Mosnacek <omosnace@redhat.com>
Subject: Re: Question about audit_filter_rules
Date: Wed, 16 May 2018 10:43:12 +0200
Message-ID: <CAFqZXNvqdwXY4-6+NSVvKX3UAv5=qFobJMkGqszGFW1kDWhvLQ@mail.gmail.com>
References: <CAFqZXNvNscyn4d7y0wJH-=NMNit=xQ5R_-buT1Lzc+r87FrHng@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <linux-audit-bounces@redhat.com>
Received: from mx1.redhat.com (ext-mx06.extmail.prod.ext.phx2.redhat.com
	[10.5.110.30])
	by smtp.corp.redhat.com (Postfix) with ESMTPS id 5B779600CD
	for <linux-audit@redhat.com>; Wed, 16 May 2018 08:43:29 +0000 (UTC)
Received: from mail-oi0-f69.google.com (mail-oi0-f69.google.com
	[209.85.218.69])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by mx1.redhat.com (Postfix) with ESMTPS id 9A898445D1
	for <linux-audit@redhat.com>; Wed, 16 May 2018 08:43:29 +0000 (UTC)
Received: by mail-oi0-f69.google.com with SMTP id a18-v6so2601636oiy.14
	for <linux-audit@redhat.com>; Wed, 16 May 2018 01:43:29 -0700 (PDT)
In-Reply-To: <CAFqZXNvNscyn4d7y0wJH-=NMNit=xQ5R_-buT1Lzc+r87FrHng@mail.gmail.com>
List-Unsubscribe: <https://www.redhat.com/mailman/options/linux-audit>,
	<mailto:linux-audit-request@redhat.com?subject=unsubscribe>
List-Archive: <https://www.redhat.com/archives/linux-audit>
List-Post: <mailto:linux-audit@redhat.com>
List-Help: <mailto:linux-audit-request@redhat.com?subject=help>
List-Subscribe: <https://www.redhat.com/mailman/listinfo/linux-audit>,
	<mailto:linux-audit-request@redhat.com?subject=subscribe>
Sender: linux-audit-bounces@redhat.com
Errors-To: linux-audit-bounces@redhat.com
To: Linux-Audit Mailing List <linux-audit@redhat.com>
Cc: Richard Guy Briggs <rgb@redhat.com>
List-Id: linux-audit@redhat.com

I found more inconsistencies:
[...]
case AUDIT_GID:
        result = audit_gid_comparator(cred->gid, f->op, f->gid);
        if (f->op == Audit_equal) {
               if (!result)
                       result = in_group_p(f->gid);
        } else if (f->op == Audit_not_equal) {
                if (result)
                        result = !in_group_p(f->gid);
        }
        break;
case AUDIT_EGID:
        result = audit_gid_comparator(cred->egid, f->op, f->gid);
        if (f->op == Audit_equal) {
                if (!result)
                        result = in_egroup_p(f->gid);
        } else if (f->op == Audit_not_equal) {
               if (result)
                        result = !in_egroup_p(f->gid);
        }
        break;
[...]

The in_[e]group_p functions match the current task's group list.
Unfortunately there don't seem to be functions in the kernel that
would do the same for arbitrary struct cred pointers, we may need to
add these to fix this.

See the definition of in_group_p for reference:
https://elixir.bootlin.com/linux/latest/source/kernel/groups.c#L219

2018-05-16 8:57 GMT+02:00 Ondrej Mosnacek <omosnace@redhat.com>:
> Hi,
>
> I noticed this suspicious line in the definition of the
> audit_filter_rules function in auditsc.c:
>
> [...]
> case AUDIT_SESSIONID:
>         sessionid = audit_get_sessionid(current);     // <--- HERE
>         result = audit_comparator(sessionid, f->op, f->val);
>         break;
> [...]
>
> Here, the sessionid is retrieved from the current task pointer, while
> all the other code in this function compares against the tsk task
> pointer. It seems that it is not always guaranteed that tsk ==
> current, so my question is: Is it intentional for some reason or
> should it be tsk instead of current?
>
> Thanks,
> --
> Ondrej Mosnacek <omosnace at redhat dot com>
> Associate Software Engineer, Security Technologies
> Red Hat, Inc.



-- 
Ondrej Mosnacek <omosnace at redhat dot com>
Associate Software Engineer, Security Technologies
Red Hat, Inc.