From mboxrd@z Thu Jan 1 00:00:00 1970 From: F Rafi Subject: Re: Filtering Connect syscalls for af_inet only Date: Thu, 5 Feb 2015 14:06:03 -0500 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6177761428257933309==" Return-path: Received: from mx1.redhat.com (ext-mx14.extmail.prod.ext.phx2.redhat.com [10.5.110.19]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t15J6BHY020552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 5 Feb 2015 14:06:12 -0500 Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t15J63sv014514 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=FAIL) for ; Thu, 5 Feb 2015 14:06:05 -0500 Received: by mail-wg0-f50.google.com with SMTP id b13so9248381wgh.9 for ; Thu, 05 Feb 2015 11:06:03 -0800 (PST) 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: Paul Moore Cc: "linux-audit@redhat.com" List-Id: linux-audit@redhat.com --===============6177761428257933309== Content-Type: multipart/alternative; boundary=047d7beba1bacd3cb2050e5bfe18 --047d7beba1bacd3cb2050e5bfe18 Content-Type: text/plain; charset=UTF-8 I did some digging and now I understand the different size variations of sockaddr_storage. I guess I can just filter on a2!=6e then. And we'd have to keep an eye out for x86 systems. I understand that x86_64 does not use socketcall() but, do you know if multiarch support somehow allows 32bit apps on x86_64 to use / translate these calls? Thanks again! Farhan On Thu, Feb 5, 2015 at 10:38 AM, Paul Moore wrote: > On Thu, Feb 5, 2015 at 10:31 AM, F Rafi wrote: > > Ahh..thanks Paul! > > > > Is there a better way to intercept outbound network access calls while > > avoiding af_unix? > > I'm not sure, I'm not overly familiar with the auditd/auditctl > filtering capabilities. There are several people on this list that > are far more knowledgeable about that than me. > > > I assume sockaddr_storage is just a different size (I think 128?) > > The idea behind the sockaddr_storage struct was to create a structure > that could be used to represent any address family that the system > supports. I don't believe there is a standard size across OSes due to > different level of support, padding, etc; in other words, it's > probably best not to rely on a specific size of sockaddr_storage. > > -- > paul moore > www.paul-moore.com > --047d7beba1bacd3cb2050e5bfe18 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I did some digging and now I understand the different size= variations of sockaddr_storage. I guess I can just filter on a2!=3D6e then= .

And we'd have to keep an eye out for x86 systems. = I understand that x86_64 does not use socketcall() but, do you know if mult= iarch support somehow allows 32bit apps on x86_64 to use / translate these = calls?

Thanks again!
Farhan
<= div class=3D"gmail_extra">
On Thu, Feb 5, 201= 5 at 10:38 AM, Paul Moore <paul@paul-moore.com> wrote:
=
On Thu, Feb 5, 2015 at 10:3= 1 AM, F Rafi <farhanible@gmail.c= om> wrote:
> Ahh..thanks Paul!
>
> Is there a better way to intercept outbound network access calls while=
> avoiding af_unix?

I'm not sure, I'm not overly familiar with the auditd/auditc= tl
filtering capabilities.=C2=A0 There are several people on this list that are far more knowledgeable about that than me.

> I assume sockaddr_storage is just a different size (I think 128?)

The idea behind the sockaddr_storage struct was to create a structur= e
that could be used to represent any address family that the system
supports.=C2=A0 I don't believe there is a standard size across OSes du= e to
different level of support, padding, etc; in other words, it's
probably best not to rely on a specific size of sockaddr_storage.

--
paul moore
www.paul-moore.com<= /a>

--047d7beba1bacd3cb2050e5bfe18-- --===============6177761428257933309== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============6177761428257933309==--