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

On Tuesday, October 11, 2016 4:42:58 PM EDT Paul Moore wrote: > On Tue, Oct 11, 2016 at 3:22 PM, Steve Grubb <sgrubb(a)redhat.com&gt; wrote: > > 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&gt; 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. > > Wait a minute ... what happened to the loginuid_set patches? Didn't > those get merged to userspace? I'm reviewing this patch set for merging now that we are past all the 2.6 bug fixing.