[userspace PATCH v2 0/2] Add support for loginuid_set

[Steve Grubb]

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 at 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