6:37 a.m.
As of now there are so many proposed fields in the audit event log , if I
wanted to one proposed field which is of not use as much ,which one can I
chose for ?
7:06 a.m.
Sowndarya,
Are you are asking how do you propose another public field name to be
added to the list in
https://people.redhat.com/sgrubb/audit/audit-events.txt ?
If so, I'd suggest you provide
a. Proposed field name
b. Description of it's content.
c. Describe how it's going to be used.
The list can then make comment and/or provide advice.
Steve,
Perhaps we could update the above document to advise users what they
should offer in such a proposal.
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.
Hopefully I am not reading too much into the original request.
Regards
On Thu, 2016-02-11 at 18:07 +0530, Sowndarya K wrote:
As of now there are so many proposed fields in the audit event log ,
if I wanted to one proposed field which is of not use as much ,which
one can I chose for ?
--
Linux-audit mailing list
Linux-audit(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
1:04 p.m.
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
12:57 p.m.
On Thursday, February 11, 2016 06:07:56 PM Sowndarya K wrote:
As of now there are so many proposed fields in the audit event log ,
if I
wanted to one proposed field which is of not use as much ,which one can I
chose for ?
The audit event known fields is kind of an agreement on what fields names shall
be and what goes in them. There is a larger context in that events of the same
type must have the same fields, in the same order, and using the same
representation. Otherwise no one can ever analyse events because nothing has
order.
So, what is it you are trying to do? That would be a more helpful question so
that we can give you a more rounded answer.
-Steve
3236
days inactive
3237
days old
linux-audit@lists.linux-audit.osci.io
3 comments
3 participants
participants (3)
-
Burn Alting -
Sowndarya K -
Steve Grubb