linux-kernel - Re: [PATCH] audit: skip sessionid sentinel value when auto-incrementing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20161118022732.GG24491@madcap2.tricolour.ca>
Date:   Thu, 17 Nov 2016 21:27:32 -0500
From:   Richard Guy Briggs <rgb@...hat.com>
To:     Paul Moore <paul@...l-moore.com>
Cc:     linux-audit@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] audit: skip sessionid sentinel value when
 auto-incrementing

On 2016-11-17 18:34, Paul Moore wrote:
> On Tue, Nov 15, 2016 at 3:49 AM, Richard Guy Briggs <rgb@...hat.com> wrote:
> > On 2016-11-14 15:17, Paul Moore wrote:
> >> On Thu, Nov 10, 2016 at 1:41 AM, Richard Guy Briggs <rgb@...hat.com> wrote:
> >> > The value (unsigned int)-1 is used as a sentinel to indicate the
> >> > sessionID is unset.  Skip this value when the session_id value wraps.
> >> >
> >> > Signed-off-by: Richard Guy Briggs <rgb@...hat.com>
> >> > ---
> >> >  kernel/auditsc.c |    5 ++++-
> >> >  1 files changed, 4 insertions(+), 1 deletions(-)
> >>
> >> Since we haven't merged the session ID kernel patches into audit#next
> >> yet, why don't you just squash this patch in with the session ID patch
> >> and resubmit upstream in one nice neat patch.
> >
> > This was an existing bug regardless of new functionality added, so the
> > fix should not be buried in a new feature patch.
> 
> No, it's not an existing bug.  The existing code simply reports/logs
> the session ID, it doesn't filter on it, so there are no magic values
> to worry about.

The existing code autoincrements through sessionID==-1.  The existing
code (ausearch and aureport) reports and logs the sessionID and there
are existing reporting tools that are able to filter on sessionID even
though kernel filters don't yet exist for them.  Therefore, it is
possible for the counter to roll and to erroneously report that the
value is unset.

Steve, am I wrong here?

> >> > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> >> > index 5abf1dc..e414dfa 100644
> >> > --- a/kernel/auditsc.c
> >> > +++ b/kernel/auditsc.c
> >> > @@ -2025,8 +2025,11 @@ int audit_set_loginuid(kuid_t loginuid)
> >> >                 goto out;
> >> >
> >> >         /* are we setting or clearing? */
> >> > -       if (uid_valid(loginuid))
> >> > +       if (uid_valid(loginuid)) {
> >> >                 sessionid = (unsigned int)atomic_inc_return(&session_id);
> >> > +               if (unlikely(sessionid == (unsigned int)-1))
> >> > +                       sessionid = (unsigned int)atomic_inc_return(&session_id);
> >> > +       }
> >> >
> >> >         task->sessionid = sessionid;
> >> >         task->loginuid = loginuid;
> >>
> >> paul moore
> >
> > - RGB
> 
> paul moore

- RGB

--
Richard Guy Briggs <rgb@...hat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635