On Wed, Oct 12, 2016 at 2:02 PM, Steve Grubb <sgrubb(a)redhat.com> wrote:
On Thursday, August 18, 2016 2:47:33 PM EDT Richard Guy Briggs
wrote:
> Add sessionid_set field option from kernel uapi macro SESSIONID_SET to
> enable specifying that sessionID is set or not in user filters.
Is there any compelling reason to support two differents fields that essentially
decide how to audit sessions? I think its a bit clunky to expect that people
write rules
-a always,exit -S open -F path=/path/file -F sessionid>0
but if you want to record daemons, then its not as simple as using -1 which is
what is in the logs and the intuitive answer. Instead you have to use a new
field.
-a always,exit -S open -F path=/path/file -F sessionid_set=0
But then you can also do the first rule as:
-a always,exit -S open -F path=/path/file -F sessionid_set=1
So, we have 2 ways of doing almost the same thing. I don't really like this.
I originally thought the loginuid_set filter functionality was added
to satisfy a request made by you for the audit userspace; I suggested
to Richard that we do the same for the session ID since there were
some definite similarities. However, having looked back at the
original motivation for adding the loginuid_set functionality, I don't
we will face the same problem with the session ID. If Richard can't
think of any compelling reason to keep a dedicated sessionid_set
filter, I think we can drop it.
Further, while I understand why Eric B. needed to make the internal
audit kernel changes to the loginuid code (and other audit UID/GID
bits for that matter), I'm less convinced on the need to change the
kernel/userspace filter API to add the loginuid_set capability.
However, that was before my time, and it's done now, we can't yank it
out at this point.
--
paul moore
www.paul-moore.com