From mboxrd@z Thu Jan  1 00:00:00 1970
From: Eric Paris <eparis@redhat.com>
Subject: Re: [RFC][PATCH] audit: log join and part events to the read-only
	multicast log socket
Date: Wed, 22 Oct 2014 11:08:02 -0400
Message-ID: <1413990482.30946.80.camel@localhost>
References: <30ef5c1ba42b52953e5684a0322975c3f0fadc77.1412706089.git.rgb@redhat.com>
	<1978142.LNMGsIevqD@x2> <1413988212.30946.71.camel@localhost>
	<8697195.1rfEK9eruo@x2>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <linux-audit-bounces@redhat.com>
In-Reply-To: <8697195.1rfEK9eruo@x2>
List-Unsubscribe: <https://www.redhat.com/mailman/options/linux-audit>,
	<mailto:linux-audit-request@redhat.com?subject=unsubscribe>
List-Archive: <https://www.redhat.com/archives/linux-audit>
List-Post: <mailto:linux-audit@redhat.com>
List-Help: <mailto:linux-audit-request@redhat.com?subject=help>
List-Subscribe: <https://www.redhat.com/mailman/listinfo/linux-audit>,
	<mailto:linux-audit-request@redhat.com?subject=subscribe>
Sender: linux-audit-bounces@redhat.com
Errors-To: linux-audit-bounces@redhat.com
To: Steve Grubb <sgrubb@redhat.com>
Cc: Richard Guy Briggs <rgb@redhat.com>, linux-audit@redhat.com
List-Id: linux-audit@redhat.com

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 if they exist, meaning
> > > that software compiled on a new kernel runs on an old kernel, it will be
> > > reading random stack or heap to make decisions. The correct solution
> > > would be to make a new struct with planned expansion capability with
> > > version as the first element so any changes can be signaled. This new
> > > struct would be sent using a new netlink command.
> > 
> > Incorrect.  The length of the message makes it perfectly clear how much
> > data the kernel sent, and thus if that data includes the version or
> > backlog_wait_time.  I thought this had been discussed before...
> > 
> > The answer is 'check how much data you got from the kernel'
> 
> Is the padding the same for all arches? :-)

completely irrelevant...

The code in audit_get_reply() seems like poor practice...  You aren't
doing any sanity checks on the data coming back.  I guess that's why
userspace has so much trouble handling things.  It's just completely
ignore the length the kernel gave you...