* Adding New field into audit records
@ 2016-03-21 6:44 Deepika Sundar
2016-03-21 8:31 ` Burn Alting
0 siblings, 1 reply; 2+ messages in thread
From: Deepika Sundar @ 2016-03-21 6:44 UTC (permalink / raw)
To: linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 220 bytes --]
Hi All,
Audit log contains already defined <name>=<value> pair in each record.Is
there any possibility to add new field <name>=<value>? and Is there any
compatibility issues associated with it ? please specify if any.
[-- Attachment #1.2: Type: text/html, Size: 294 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Adding New field into audit records
2016-03-21 6:44 Adding New field into audit records Deepika Sundar
@ 2016-03-21 8:31 ` Burn Alting
0 siblings, 0 replies; 2+ messages in thread
From: Burn Alting @ 2016-03-21 8:31 UTC (permalink / raw)
To: Deepika Sundar; +Cc: linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 2218 bytes --]
On Mon, 2016-03-21 at 12:14 +0530, Deepika Sundar wrote:
> Hi All,
>
>
>
> Audit log contains already defined <name>=<value> pair in each
> record.Is there any possibility to add new field <name>=<value>? and
> Is there any compatibility issues associated with it ? please specify
> if any.
We discussed this last month as per below. So what do you want to do?
On Friday, February 12, 2016 12:06:54 AM Burn Alting wrote:
> Steve,
>
> Perhaps we could update the above document to advise users
what they
> should offer in such a proposal.
Good point. Usually they come to the list and say I am working
on a daemon
that needs to write something to the audit log whenever this
kind of thing
happens. How should I record it.
This leads to a better conversation because not everything is a
candidate for
the audit logs. That doesn't mean it doesn't need to be
recorded, it just
means it needs to go somewhere else.
For example, tcp_wrappers can reject connections. Should that go
into audit
logs automatically? No way. Same with web application access
control. These
are important enough to be logged, but they belong in an
application log.
> Perhaps further, we could offer a generic solution on how one
could
> define a 'non-public' field name. That is, a 'non-public'
field is one
> which could not, via it's nomenclature, conflict with a
current or
> future 'public' (aka published) field name. Such non-public
fields could
> then be used by capability that only needs the audit source
and audit
> consumer to be aware of the field.
That's a good point. I'm pretty sure 'private-' will never be
used for a prefix
to any field. That said, if this is going into an existing
event, we really
need to have a discussion about that. This affects all third
party's that try
to make sense of the audit logs,
-Steve
[-- Attachment #1.2: Type: text/html, Size: 2542 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2016-03-21 8:39 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-03-21 6:44 Adding New field into audit records Deepika Sundar
2016-03-21 8:31 ` Burn Alting
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.