Re: [userspace PATCH v2 0/2] Add support for loginuid_set
On Tuesday, October 11, 2016 2:27:54 PM EDT Richard Guy Briggs wrote:
On 2016-10-11 12:40, Steve Grubb wrote:
> On Monday, October 10, 2016 5:10:39 PM EDT Paul Moore wrote:
> > On Mon, Oct 10, 2016 at 1:24 PM, Steve Grubb <sgrubb(a)redhat.com> wrote:
> > > On Thursday, August 18, 2016 2:18:55 PM EDT Richard Guy Briggs wrote:
> > >> loginuid_set support should have been added to userspace when it was
> > >> added to the kernel around v3.10. Add it before we do similar for
> > >> sessionID and sessionID_set.
> > >
> > > If this were accepted, how would this change writing rules? IOW, can
> > > you
> > > give an example rule so we can see what this looks like?
> >
> > We have a RFE feature page which documents some rule examples:
> >
> > *
> > https://github.com/linux-audit/audit-kernel/wiki/RFE-Session-ID-User-Fil
> > ter
>
> OK, thanks. This is helpful. So, what is the difference between these
> rules?
>
> -a always,exit -F path=/tmp/sessionid_test -F loginuid=-1
>
> -a always,exit -F path=/tmp/sessionid_set_test -F loginuid_set=0
The only difference is one flag in the kernel to indicate how it was
invoked to be able to report when queried exactly the same way it was
invoked, but there is no difference in the actual behaviour of the
filter. This was added because of your report that "f24=0" was reported
instead of loginuid_set=0 for backwards compatibility.
OK. Generally its bad to have 2 ways to do the same thing. People use SCAP
content to check system configurations. If there's two ways to do the same
thing, then someone can accidentally choose the wrong way and fail their scan.
We run into this in the past where we allowed -a exit,always and -a
always,exit. All the rules had to be reworked to be consistent. Therefore, I
would recommend not using the loginuid_set option. We still get questions
about -w /path/file -p wa vs -a always,exit -F path=/path/file -F perm=wa. But
that one is so deeply embedded that it should not be fixed.
Going forward, the implementation of the sessionid_set field (which
works similarly) will not allow an unset value of sessionid since these
are a new addition that didn't need to accomodate backward
compatibility.
As long as we can trigger on sessionid=-1, then we are fine.
-Steve