|Main Archive Page > Month Archives > linux-security-module archives|
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> writes:
> 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.
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to email@example.com More majordomo info at http://vger.kernel.org/majordomo-info.html