On Tue, Oct 11, 2016 at 5:31 PM, Steve Grubb <[email protected]> wrote: > On Tuesday, October 11, 2016 4:54:26 PM EDT Paul Moore wrote: >> On Tue, Oct 11, 2016 at 4:50 PM, Steve Grubb <[email protected]> wrote: >> > On Tuesday, October 11, 2016 4:42:58 PM EDT Paul Moore wrote: >> >> On Tue, Oct 11, 2016 at 3:22 PM, Steve Grubb <[email protected]> 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 <[email protected]> >> > >> > 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-Us >> >> >> > > er-> >> > > 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. >> >> Ah, nevermind ... I confused loginuid and sessionid, sorry about the >> confusion. >> >> Anyway, I thought the desire for having a dedicated "is the loginuid >> value set?" filter came from userspace? If not, where did this >> requirement come from? > > I don't know where it came from. We have always used -1 for unset loginuid and > session id.
Looking back through the git logs, it looks like it originally came out of the user namespace work by Eric Biederman. -- paul moore security @ redhat -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
