From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stephan Mueller <smueller@atsec.com>
Subject: Re: Bad bug in remote logging
Date: Tue, 12 Apr 2011 09:23:08 +0200
Message-ID: <201104120923.08354.smueller@atsec.com>
References: <201104111900.47508.sgrubb@redhat.com> <4DA3C494.2090909@hp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <linux-audit-bounces@redhat.com>
Received: from mx1.redhat.com (ext-mx13.extmail.prod.ext.phx2.redhat.com
	[10.5.110.18])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id p3C7NBQF005934
	for <linux-audit@redhat.com>; Tue, 12 Apr 2011 03:23:11 -0400
Received: from mail.atsec.com (mail.atsec.com [195.30.99.214])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p3C7NAZr012536
	for <linux-audit@redhat.com>; Tue, 12 Apr 2011 03:23:10 -0400
Received: from mail.atsec.com (localhost [127.0.0.1])
	by mail.atsec.com (Postfix) with ESMTP id C931678076
	for <linux-audit@redhat.com>; Tue, 12 Apr 2011 09:23:09 +0200 (CEST)
In-Reply-To: <4DA3C494.2090909@hp.com>
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: linux-audit@redhat.com
List-Id: linux-audit@redhat.com

Am Dienstag, 12. April 2011, um 05:18:44 schrieb Linda Knippers:

Hi Linda,

> Steve Grubb wrote:
> > Hello,
> > 
> > There was a bug reported to day that I think merits an email and/or
> > discussion.
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=695419
> > =================================
> > audisp-remote does
> > 
> >>               memset (&address, 0, sizeof(address));
> >>               address.sin_family = htons(AF_INET);
> >>               address.sin_port = htons(config.local_port);
> >>               address.sin_addr.s_addr = htonl(INADDR_ANY);
> > 
> > which shows in strace as
> > 
> >> bind(3, {sa_family=0x200 /* AF_??? */,
> >> sa_data="\0<\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) =

Bind does not do anything with the family - it just calls the bind callback 
function set for the protocol by the socket syscall. What is the socket 
syscall saying here?

Note that the socket syscall (specifically __sock_create) has the following 
code for the family:

        if (family < 0 || family >= NPROTO)
                return -EAFNOSUPPORT;

And NPROTO is defined as decimal 39 (in 2.6.38). Hence, 0x200 as a family does 
not work for socket - the socket syscall would have returned an error.

If for some reason the socket syscall uses AF_INET and diverts into IPv4, 
sin_family does not seem to be used unless you have a socket-specific bind 
function (e.g. RAW sockets).

To make a final determination on the impact, I would check:

- strace for socket syscall

- tcpdump on the connection

Ciao
Stephan