Message-ID: <m2sl2p8x8e.fsf@synack.fr>
Date:	Thu, 29 Nov 2007 05:57:37 +0100
From:	Samir Bellabes <sam@...ack.fr>
To:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Cc:	jmorris@...ei.org, herbert@...dor.apana.org.au,
	netdev@...r.kernel.org, davem@...emloft.net,
	linux-security-module@...r.kernel.org, kaber@...sh.net,
	netfilter-devel@...ts.netfilter.org, sds@...ho.nsa.gov
Subject: Re: [PATCH net-2.6.25] Add packet filtering based on process'ssecurity context.

Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp> writes:

> Hello.
>
> James Morris wrote:
>> From memory, one approach under discussion was to add netfilter hooks to 
>> the transport layer, which could be invoked correctly by each type of 
>> protocol when the target process is selected.
>> 
>> If this is done for netfilter, then an LSM hook is probably not needed at 
>> all, as security modules can utilize netfilter hooks directly.
>
> Patrick McHardy says (at http://marc.info/?l=linux-netdev&m=118495005800410&w=2 )
> "Even with socket filters netfilter doesn't know the final receipient
>  process, that is not known until it calls recvmsg and the data is read,
>  which is too late for netfilter."

Indeed, but there is another approach, using libnetfilter_queue.
I have the same goal as TOMOYO, let the user decided filtering, with
informations coming from LSM hook, which give more datas to the users,
specially with the relationship between the socket and the
user/process. 

My approach is to get the informations regarding the socket from
socket(), bind() and and accept() syscalls hooks.
Pushing this informations to userspace. Here the user can refuse or
accept the sycalls.
Then, for incoming data, we are using libnetfilter_queue from userspace.
And we can make a relation between the first delivered packet by
netfilter with our informations from the LSM hooks at socket(), bind() and
accept().

Let me get a example based on TCP/IP:
process X is executing this :
  - userspace  : socket()
  - kernel : sys_socket()
  - LSM : socket_create() -> pushing (process id, userid, protocol,
                             IP/ports) infos to userspace
  - userspace : bind()
  - kernel : sys_bind()
  - LSM : socket_bind() -> pushing (process id, userid, protocol,
                           IP/ports) infos to userspace
  - userspace : listen()
  - kernel : sys_listen() -> pushing (process id, userid, protocol,
                             IP/ports) infos to userspace

As now the application is listening on a port, we are waiting for the
TCP SYN packet coming from remote side.
When TCP SYN arrive, we can capture it with libnetfilter_queue.

Then we can make a relation between informations in the hearders from
the TCP SYN packet: (src/dst address IPs, dst/src/ ports, procotol) ie
the netfilter tuple, and our informations from the LSM hooks, ie we know
that process X did socket(), bind(), listen() on the same src address
IP, src port and protocol.

Then we can decide to drop or accept this packet, with
libnetfilter_queue.

this approach seems better because we already have *all* the tools from
the kernel side, except form the managing LSM interface with userspace,
but I already have some improvements on this (patch attached)

Please consider this approach as a better side because using netfilter
for filtering packets is the best solution, and that we can make a
relation between socket and packets with this idea, and this feature can
stay in userspace.

FYI, this project is named "network events connector", some people from
netfilter-devel list may already know it, because I made a talk about it
for the last netfilter workshop.

thank you.


View attachment "cn_net.patch" of type "text/x-patch" (35259 bytes)

Powered by blists - more mailing lists