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
>
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/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 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.
audit_log_format(ab, "feature=%s old=%u new=%u old_lock=%u new_lock=%u
res=%
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 w
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
> >
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:
> >
> >
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=
> >
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
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
assumpt
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
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
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 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
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 ch
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:3
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:
>> >
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 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
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
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 m
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'
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?
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
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 or
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 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
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 ke
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
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'
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: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 do
[NOTE: Since we are wandering off the original topic I took the liberty of
trimming the To/CC line to just the audit list folks, feel free to add back as
necessary.]
On Tuesday, October 21, 2014 09:24:05 PM Richard Guy Briggs wrote:
> On 14/10/21, Paul Moore wrote:
> > On Tuesday, October 21, 20
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 grou
On 14/10/21, Eric Paris wrote:
> On Tue, 2014-10-21 at 17:08 -0400, Richard Guy Briggs wrote:
> > 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 clie
On Tuesday, October 21, 2014 06:30:29 PM Eric Paris wrote:
> I've always hated the fact that we include this in ANY current audit
> message. I truly believe we need two new record types.
>
> AUDIT_PROCESS_INFO
> AUDIT_EXTENDED_PROCESS_INFO
>
> What does my UID have to do with a syscall? Why is
On Tue, 2014-10-21 at 17:08 -0400, Richard Guy Briggs wrote:
> 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 aud
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.
>
>
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 conn
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, bindi
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 the
> > AUDIT_NLGRP_READLOG group.
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 Saturday, October 11, 2014 11:42:06 AM Steve Grubb wrote:
> On Tue, 07 Oct 2014 18:06:51 -0400
>
> Paul Moore 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
On Tue, 07 Oct 2014 18:06:51 -0400
Paul Moore 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() could use aud
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() could use audit_log_session_info(), but they are
> in slightly different ord
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 disconne
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
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 uid=
48 matches
Mail list logo
