Paul Moore wrote:
On Tue, Oct 11, 2016 at 12:07 PM, Steve Grubb
<sgrubb(a)redhat.com> wrote:
> On Monday, October 10, 2016 2:48:23 PM EDT L. A. Walsh wrote:
>
> I.e. the exact opposite of your (Steve)'s statement. Wondered if that was
> a misread or newer information...<*idle curiosity*>.
>
> Either way sounds like it would be "nice" to differentiate a
"read" from
> a "write" in this syscall if it is to be useful.
>
> I agree. But the problem with this syscall is that the operation
> is part of a data structure that is passed by address to the kernel.
> There currently is no good way to filter its uses because the audit subsystem can
only look at the actual argument passed. I think there
> may be an issue opened for this on github.
>
Yep, link below:
*
https://github.com/linux-audit/audit-kernel/issues/10
A parallel that may be useful -- the "file" program that ID's
files,
can't just
look at the value of a field, but values pointed-to, by-a-field.
Without the ability to record the value of a "pointer", I'd think audit was
a bit hamstrung. At the destination of the pointer, one might want to
support
other data types than just 'value' (usernames, groupnames,
structures...etc).
Sad, but one might want to record an array of groups pointed to by some
field
as well.
Is it the case that nothing else in audit needs indirect information?
But as long as the data structure is defined by the kernel, I'd think it
a valid object to be able to audit...but that's my wanting flexibility.
Even wireshark/network monitoring needed to have the ability to compile
the filter into the kernel to create satifactory performance. Might not
audit
need similar?