From mboxrd@z Thu Jan 1 00:00:00 1970 From: Burn Alting Subject: Re: Adding New field into audit records Date: Mon, 21 Mar 2016 19:31:18 +1100 Message-ID: <1458549078.6860.91.camel@swtf.swtf.dyndns.org> References: Reply-To: burn@swtf.dyndns.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0356240491535331374==" Return-path: Received: from mx1.redhat.com (ext-mx06.extmail.prod.ext.phx2.redhat.com [10.5.110.30]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2L8dfNU006882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 21 Mar 2016 04:39:41 -0400 Received: from swtf.swtf.dyndns.org (203-219-87-38.static.tpgi.com.au [203.219.87.38]) by mx1.redhat.com (Postfix) with ESMTP id A69C4689 for ; Mon, 21 Mar 2016 08:39:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by swtf.swtf.dyndns.org (Postfix) with ESMTP id 819DB3018F3E0 for ; Mon, 21 Mar 2016 19:31:21 +1100 (AEDT) Received: from swtf.swtf.dyndns.org ([127.0.0.1]) by localhost (gateway.swtf.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VS5aeyU45a1z for ; Mon, 21 Mar 2016 19:31:19 +1100 (AEDT) Received: from localhost (localhost [127.0.0.1]) by swtf.swtf.dyndns.org (Postfix) with ESMTP id F31E03015915B for ; Mon, 21 Mar 2016 19:31:18 +1100 (AEDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Deepika Sundar Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com --===============0356240491535331374== Content-Type: multipart/alternative; boundary="=-+yamuJ8tlHlffS812BfT" --=-+yamuJ8tlHlffS812BfT Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Mon, 2016-03-21 at 12:14 +0530, Deepika Sundar wrote: > Hi All, > > > > Audit log contains already defined = pair in each > record.Is there any possibility to add new field =? 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 --=-+yamuJ8tlHlffS812BfT Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit 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

--=-+yamuJ8tlHlffS812BfT-- --===============0356240491535331374== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============0356240491535331374==--