On Tue, Oct 11, 2016 at 5:37 PM, L. A. Walsh <l...@tlinx.org> wrote:
> Paul Moore wrote:
>> On Tue, Oct 11, 2016 at 12:07 PM, Steve Grubb <sgr...@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
>>> 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
> 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
> other data types than just 'value' (usernames, groupnames,
> Sad, but one might want to record an array of groups pointed to by some
> 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
> need similar?
In order to provide the desired audit granularity for the adjtimex()
syscall we would need to add some additional audit hooks to that
syscall. I've yet to see a good way of inspecting non-scalar objects
in a generic manner, we need to handle it on a case-by-case basis.
Linux-audit mailing list