From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: audit_status in kernel Date: Mon, 10 Mar 2014 18:25:46 -0400 Message-ID: <27892229.0ex1XAQCcX@x2> References: <2266202.J6IrG6ma9a@x2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <2266202.J6IrG6ma9a@x2> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com Cc: rgb@redhat.com List-Id: linux-audit@redhat.com On Monday, March 10, 2014 05:48:06 PM Steve Grubb wrote: > Hello, > > I was looking at a new kernel and see that the audit_status structure has > changed. The first member of the structure is a bit mask that tells what all > is in the structure. So, if we add this: > > __u32 version; /* audit api version number */ > __u32 backlog_wait_time;/* message queue wait timeout */ > }; > > Then we need to have a define for those two: > > #define AUDIT_STATUS_BACKLOG_LIMIT 0x0010 > +#define AUDIT_STATTUS_VERSION 0x0020 > -#define AUDIT_STATUS_BACKLOG_WAIT_TIME 0x0020 > +#define AUDIT_STATUS_BACKLOG_WAIT_TIME 0x0040 > > IOW, each entry in the structure is supposed to have a mask value. Actually, I think the problems are worse. We have the issue of an expanding data structure over time as new things get added. But yet we have a fixed sized audit_status structure. I could copy that into the audit package's source code so that I have the new structure definition. But I will have to do the same thing each time. Also, how would an old kernel tolerate a bigger audit_status structure being sent with AUDIT_SET commands by a new auditctl? What we should do is leave AUDIT_GET the way it was. We should then define AUDIT_GET_EXT and then use it a lot like audit_rule_data which has struct audit_status_ext { __u32 field_count; __u32 fields[AUDIT_MAX_FIELDS]; __u32 values[AUDIT_MAX_FIELDS]; }; Then insert the field identifier in fields and the value in the other. This way the format is defined once and we can reuse it for a long time. >>From user space, the migration would be easy. Old auditctl still uses AUDIT_GET. New auditctl would try AUDIT_GET_EXT and if that's not recognized, drop back to AUDIT_GET. Then one day down the road we remove AUDIT_GET in the kernel. This is how we did the migration from AUDIT_RULES to AUDIT_RULES_DATA. -Steve