From: "L. A. Walsh" <lkml@tlinx.org>
To: Paul Moore <paul@paul-moore.com>
Cc: "Jarsulic, Michael [CRI]" <mjarsulic@bsd.uchicago.edu>,
linux-audit@redhat.com
Subject: Re: Question regarding ntpd
Date: Tue, 11 Oct 2016 14:37:16 -0700 [thread overview]
Message-ID: <57FD5B8C.1080909@tlinx.org> (raw)
In-Reply-To: <CAHC9VhSbx6_9HHGMqYPE40peXjV5CQSBryPmsHHfJAyQAbz=3A@mail.gmail.com>
Paul Moore wrote:
> On Tue, Oct 11, 2016 at 12:07 PM, Steve Grubb <sgrubb@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?
next prev parent reply other threads:[~2016-10-11 21:37 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-27 22:05 Question regarding ntpd Sullivan, Daniel [CRI]
2016-09-27 23:16 ` Steve Grubb
2016-09-28 0:06 ` John Jasen
2016-09-28 1:21 ` Sullivan, Daniel [CRI]
2016-09-28 0:21 ` Ryan Sawhill
2016-09-28 1:45 ` Sullivan, Daniel [CRI]
2016-09-28 1:17 ` Sullivan, Daniel [CRI]
2016-10-10 21:48 ` L. A. Walsh
2016-10-11 16:07 ` Steve Grubb
2016-10-11 20:49 ` Paul Moore
2016-10-11 21:37 ` L. A. Walsh [this message]
2016-10-13 12:25 ` Paul Moore
2016-10-11 16:33 ` Ryan Sawhill
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57FD5B8C.1080909@tlinx.org \
--to=lkml@tlinx.org \
--cc=linux-audit@redhat.com \
--cc=mjarsulic@bsd.uchicago.edu \
--cc=paul@paul-moore.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.