netdev - Re: [PATCH net-2.6.25] Add packet filtering based on process'ssecurity context.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m2r6i71zuk.fsf@synack.fr>
Date:	Fri, 30 Nov 2007 17:07:31 +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@...r.kernel.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.
>
> Samir Bellabes wrote:
>> at security_socket_accept(), the user only accept the fact that the
>> application is able to go to sock->ops->accept(). That's the purpose of
>> this hook.
> Yes. This hook can't perform filtering.

By "filtering", you should mean "packets filtring", shouldn't you ?
because this hook is able to deny the accept() syscall for a process, so
it's a kind of "filtring" too.

>> After, when packet are coming, we can catch them with
>> libnetfilter_queue, and deal with filtering packets.
> Is this performed inside sock->ops->accept()?

No, it's performed from the userspace. the goal is to don't touch the
network stack at all.
after accepting a successful security_socket_accept(), the processus
will wait for client. first packet will arrived. Here we do the
filtering, and give the ability to the user to deny packets.
Dropping the TCP SYN for a TCP connection, for example, then the
process don't see the connection arrived and was dropped.

Another important point which make me sure we should need to use the
libnetfilter_queue is that the we need to work with the conntrack tool
to automatically let some connections going throught the firewall.

One example, a ftp client will listen on a arbitrary port for the
incoming data channel. This job is already handle with the conntrack_ftp
extension by netfilter.
With your tool, you will have to learn the ftp client to let incoming
connection, reach this dynamic port, so does this mean, as it's dynamic,
to allow TCP port 1024-65535 ? 
With the approach of using the libnetfilter_queue, we can first put the
network packet inside the conntrack, let the packets in the RELATED
state going trought the firewall and be ACCEPTED, and for others
packets, let the user decide.

>> here we agree. *but* in my module, the user don't judge before
>> sock->ops->accept(). He judges when packets are coming, throught the
>> libnetfilter_queue API, in userspace, and reinject packet if it's ok.
> I didn't understand what is happening.
> Is there a hook which can perform filtering inside sock->ops->accept()?

I'm not speaking anymore about socket filtering inside
sock->aps->accept(). I do filtering for sock->aps->accept() with the
netfilter tool, by handling packets directly.
So there's two thing, first dealing with socket filtering for socket(),
bind(), listen(), accept() (just to let application to have the right to
execute the syscall)
Then for managing the data inside the connection, I will use the packet
by packet way, with netfilter and libnetfilter_queue.

I really need time to made a real release, to show code. I will take it.

regards,
sam
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html