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

[Paul Moore]

On Tue, Oct 11, 2016 at 3:22 PM, Steve Grubb <sgrubb at redhat.com> 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 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.

Wait a minute ... what happened to the loginuid_set patches?  Didn't
those get merged to userspace?

-- 
paul moore
security @ redhat