On 14/10/22, Steve Grubb wrote:
On Wednesday, October 22, 2014 04:06:47 PM Paul Moore wrote:
On Wednesday, October 22, 2014 01:56:13 PM Steve Grubb wrote:
On Wednesday, October 22, 2014 11:28:46 AM Paul Moore wrote:
On Wednesday, October 22, 2014 10:25:35 AM Steve Grubb wrote:
On
On Thursday, October 30, 2014 10:48:28 AM Richard Guy Briggs wrote:
On 14/10/22, Steve Grubb wrote:
Speaking of which, I just found a typo in
AUDIT_FEATURE_CHANGE events.
Just so I don't lose this, what's the problem there? I don't see a
typo, but question the field names.
On 14/10/30, Steve Grubb wrote:
On Thursday, October 30, 2014 10:48:28 AM Richard Guy Briggs wrote:
On 14/10/22, Steve Grubb wrote:
Speaking of which, I just found a typo in
AUDIT_FEATURE_CHANGE events.
Just so I don't lose this, what's the problem there? I don't see a
typo, but
On 14/10/21, Steve Grubb wrote:
On Tuesday, October 21, 2014 05:08:22 PM Richard Guy Briggs wrote:
On 14/10/21, Steve Grubb wrote:
super crazy yuck. audit_log_task_info() ??
Its a shame we don't have a audit_log_task_info_light function which only
records:
We already have
On 14/10/22, Paul Moore wrote:
On Tuesday, October 21, 2014 09:24:05 PM Richard Guy Briggs wrote:
On 14/10/21, Paul Moore wrote:
Before we go to much farther, I'd really like us to agree that ordering is
not important, can we do that? As a follow up, what do we need to do to
make that
On 14/10/22, Steve Grubb wrote:
On Tuesday, October 21, 2014 06:30:24 PM Paul Moore wrote:
On Tuesday, October 21, 2014 03:56:10 PM Steve Grubb wrote:
Before we go to much farther, I'd really like us to agree that ordering is
not important, can we do that?
Its kind of doubtful we can do
On 10/22/2014 04:29 PM, Paul Moore wrote:
Well, like I said, It's probably safer that way as the code will work
regardless. Time to break bad habits :)
I hear you. But there's working and there's working well.
As long as we don't suffer a search response degradation by changing the
On Thursday, October 23, 2014 09:19:49 AM LC Bruzenak wrote:
On 10/22/2014 04:29 PM, Paul Moore wrote:
Well, like I said, It's probably safer that way as the code will work
regardless. Time to break bad habits :)
I hear you. But there's working and there's working well.
As long as we
On Wednesday, October 22, 2014 05:18:37 PM Steve Grubb wrote:
On Wednesday, October 22, 2014 05:00:03 PM Paul Moore wrote:
On Wednesday, October 22, 2014 04:39:49 PM Steve Grubb wrote:
Except you can have problems when the event is like this
auid= pid= old uid= new uid= res=
I
On Tuesday, October 21, 2014 06:30:24 PM Paul Moore wrote:
On Tuesday, October 21, 2014 03:56:10 PM Steve Grubb wrote:
audit_log_task_info logs too much information for typical use. There are
times when you might want to know everything about what's connecting. But
in this case, we don't
On Wed, 2014-10-22 at 10:25 -0400, Steve Grubb wrote:
12) The struct audit_status was extended to include version and
backlog_wait_time. I cannot determine at runtime if they exist, meaning that
software compiled on a new kernel runs on an old kernel, it will be reading
random stack or
On Tuesday, October 21, 2014 06:30:29 PM Eric Paris wrote:
On Tue, 2014-10-21 at 17:08 -0400, Richard Guy Briggs wrote:
On 14/10/21, Steve Grubb wrote:
audit_log_task_info logs too much information for typical use. There are
times when you might want to know everything about what's
On Tuesday, October 21, 2014 09:24:05 PM Richard Guy Briggs wrote:
On 14/10/21, Paul Moore wrote:
On Tuesday, October 21, 2014 03:56:10 PM Steve Grubb wrote:
audit_log_task_info logs too much information for typical use. There are
times when you might want to know everything about what's
On Wednesday, October 22, 2014 10:30:12 AM Eric Paris wrote:
On Wed, 2014-10-22 at 10:25 -0400, Steve Grubb wrote:
12) The struct audit_status was extended to include version and
backlog_wait_time. I cannot determine at runtime if they exist, meaning
that software compiled on a new kernel
On Wed, 2014-10-22 at 10:36 -0400, Steve Grubb wrote:
On Wednesday, October 22, 2014 10:30:12 AM Eric Paris wrote:
On Wed, 2014-10-22 at 10:25 -0400, Steve Grubb wrote:
12) The struct audit_status was extended to include version and
backlog_wait_time. I cannot determine at runtime if they
On Wed, 2014-10-22 at 10:25 -0400, Steve Grubb wrote:
1) For the *at syscalls, can we get the path from the FD being passed to be
able to reconstruct what is being accessed?
You might sometimes be able to get A path. But every time anyone ever
says THE path they've already lost. There is no
On Wednesday, October 22, 2014 10:25:35 AM Steve Grubb wrote:
On Tuesday, October 21, 2014 06:30:24 PM Paul Moore wrote:
This is getting back to my earlier concerns/questions about field
ordering, or at the very least I'm going to hijack this conversation and
steer it towards field ordering
On 10/22/2014 10:12 AM, Eric Paris wrote:
On Wed, 2014-10-22 at 10:25 -0400, Steve Grubb wrote:
1) For the *at syscalls, can we get the path from the FD being passed to be
able to reconstruct what is being accessed?
You might sometimes be able to get A path. But every time anyone ever
says
On Wednesday, October 22, 2014 10:51:49 AM LC Bruzenak wrote:
On 10/22/2014 10:12 AM, Eric Paris wrote:
On Wed, 2014-10-22 at 10:25 -0400, Steve Grubb wrote:
1) For the *at syscalls, can we get the path from the FD being passed to
be
able to reconstruct what is being accessed?
You
On Wednesday, October 22, 2014 11:28:46 AM Paul Moore wrote:
On Wednesday, October 22, 2014 10:25:35 AM Steve Grubb wrote:
On Tuesday, October 21, 2014 06:30:24 PM Paul Moore wrote:
This is getting back to my earlier concerns/questions about field
ordering, or at the very least I'm going
On Wed, 2014-10-22 at 10:51 -0500, LC Bruzenak wrote:
On 10/22/2014 10:12 AM, Eric Paris wrote:
On Wed, 2014-10-22 at 10:25 -0400, Steve Grubb wrote:
1) For the *at syscalls, can we get the path from the FD being passed to be
able to reconstruct what is being accessed?
You might
On 10/22/2014 01:18 PM, Eric Paris wrote:
On Wed, 2014-10-22 at 10:51 -0500, LC Bruzenak wrote:
On 10/22/2014 10:12 AM, Eric Paris wrote:
On Wed, 2014-10-22 at 10:25 -0400, Steve Grubb wrote:
1) For the *at syscalls, can we get the path from the FD being passed to be
able to reconstruct what
On Wednesday, October 22, 2014 02:18:00 PM Eric Paris wrote:
On Wed, 2014-10-22 at 10:51 -0500, LC Bruzenak wrote:
On 10/22/2014 10:12 AM, Eric Paris wrote:
On Wed, 2014-10-22 at 10:25 -0400, Steve Grubb wrote:
1) For the *at syscalls, can we get the path from the FD being passed
to be
On Wednesday, October 22, 2014 01:56:13 PM Steve Grubb wrote:
On Wednesday, October 22, 2014 11:28:46 AM Paul Moore wrote:
On Wednesday, October 22, 2014 10:25:35 AM Steve Grubb wrote:
On Tuesday, October 21, 2014 06:30:24 PM Paul Moore wrote:
This is getting back to my earlier
On 10/22/2014 03:06 PM, Paul Moore wrote:
But it illustrates the point. There are tools that depend on an ordering
and
format. There are more programs that just ausearch that needs to be
considered if the fields change. For example, Someone could do things like
this:
retval =
On Wednesday, October 22, 2014 04:06:47 PM Paul Moore wrote:
On Wednesday, October 22, 2014 01:56:13 PM Steve Grubb wrote:
On Wednesday, October 22, 2014 11:28:46 AM Paul Moore wrote:
On Wednesday, October 22, 2014 10:25:35 AM Steve Grubb wrote:
On Tuesday, October 21, 2014 06:30:24 PM
On Wednesday, October 22, 2014 03:34:24 PM LC Bruzenak wrote:
On 10/22/2014 03:06 PM, Paul Moore wrote:
But it illustrates the point. There are tools that depend on an
ordering and format. There are more programs that just ausearch that
needs to be considered if the fields change. For
On Wednesday, October 22, 2014 04:39:49 PM Steve Grubb wrote:
On Wednesday, October 22, 2014 04:06:47 PM Paul Moore wrote:
On Wednesday, October 22, 2014 01:56:13 PM Steve Grubb wrote:
On Wednesday, October 22, 2014 11:28:46 AM Paul Moore wrote:
On Wednesday, October 22, 2014 10:25:35 AM
On 10/22/2014 03:44 PM, Paul Moore wrote:
We haven't changed anything yet, but I strongly believe we need to do away
with field ordering. The good news is that if you explicitly search for the
field instead of relying on a fixed order the code should be more robust and
work either way. ;)
On Wednesday, October 22, 2014 05:00:03 PM Paul Moore wrote:
On Wednesday, October 22, 2014 04:39:49 PM Steve Grubb wrote:
On Wednesday, October 22, 2014 04:06:47 PM Paul Moore wrote:
On Wednesday, October 22, 2014 01:56:13 PM Steve Grubb wrote:
On Wednesday, October 22, 2014 11:28:46 AM
On Wednesday, October 22, 2014 04:11:08 PM LC Bruzenak wrote:
On 10/22/2014 03:44 PM, Paul Moore wrote:
We haven't changed anything yet, but I strongly believe we need to do away
with field ordering. The good news is that if you explicitly search for
the field instead of relying on a fixed
On 14/10/07, Richard Guy Briggs wrote:
On 14/10/07, Eric Paris wrote:
On Tue, 2014-10-07 at 14:23 -0400, Richard Guy Briggs wrote:
Log the event when a client attempts to connect to the netlink audit
multicast
socket, requiring CAP_AUDIT_READ capability, binding to the
On 14/10/21, Steve Grubb wrote:
On Tuesday, October 07, 2014 03:03:14 PM Eric Paris wrote:
On Tue, 2014-10-07 at 14:23 -0400, Richard Guy Briggs wrote:
Log the event when a client attempts to connect to the netlink audit
multicast socket, requiring CAP_AUDIT_READ capability, binding to
On Tuesday, October 21, 2014 05:08:22 PM Richard Guy Briggs wrote:
On 14/10/21, Steve Grubb wrote:
super crazy yuck. audit_log_task_info() ??
audit_log_task_info logs too much information for typical use. There are
times when you might want to know everything about what's connecting.
On Tuesday, October 21, 2014 03:56:10 PM Steve Grubb wrote:
audit_log_task_info logs too much information for typical use. There are
times when you might want to know everything about what's connecting. But
in this case, we don't need anything about groups, saved uids, fsuid, or
ppid.
Its a
On 14/10/21, Paul Moore wrote:
On Tuesday, October 21, 2014 03:56:10 PM Steve Grubb wrote:
audit_log_task_info logs too much information for typical use. There are
times when you might want to know everything about what's connecting. But
in this case, we don't need anything about groups,
On Tue, 07 Oct 2014 18:06:51 -0400
Paul Moore pmo...@redhat.com wrote:
On Tuesday, October 07, 2014 03:39:51 PM Richard Guy Briggs wrote:
I also thought of moving audit_log_task() from auditsc.c to audit.c
and using that. For that matter, both audit_log_task() and
audit_log_task_info()
Log the event when a client attempts to connect to the netlink audit multicast
socket, requiring CAP_AUDIT_READ capability, binding to the AUDIT_NLGRP_READLOG
group. Log the disconnect too.
Sample output:
time-Tue Oct 7 14:15:19 2014
type=UNKNOWN[1348] msg=audit(1412705719.316:117): auid=0
On Tue, 2014-10-07 at 14:23 -0400, Richard Guy Briggs wrote:
Log the event when a client attempts to connect to the netlink audit multicast
socket, requiring CAP_AUDIT_READ capability, binding to the
AUDIT_NLGRP_READLOG
group. Log the disconnect too.
Sample output:
time-Tue Oct 7
On 14/10/07, Eric Paris wrote:
On Tue, 2014-10-07 at 14:23 -0400, Richard Guy Briggs wrote:
Log the event when a client attempts to connect to the netlink audit
multicast
socket, requiring CAP_AUDIT_READ capability, binding to the
AUDIT_NLGRP_READLOG
group. Log the disconnect too.
40 matches
Mail list logo
