netdev - Re: [PATCH] LSM: Add security_socket_post_accept() and security_socket_post_recv

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: <200904220538.n3M5c4QI010548@www262.sakura.ne.jp>
Date:	Wed, 22 Apr 2009 14:38:04 +0900
From:	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To:	davem@...emloft.net
Cc:	paul.moore@...com, linux-security-module@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [PATCH] LSM: Add security_socket_post_accept() and security_socket_post_recv_datagram().

David Miller wrote:
> Do me a favor.  We have mechanisms by which you can queue up packets
> (even into userspace) to make policy decisions.
I know.
> 
> You can make your decision there, and if appropriate, reinject the
> packet back into the kernel input processing.
No I can't.
> 
> This is how netfilter ip_queue allows people to implement policies
> in userspace, and you could use it in the kernel and then need
> none of these ugly hooks.
I was suggested to use that approach in the past discussion.

I want to make policy decisions based on the "task_struct" who picks up
the connection/datagram.

The netfilter can't predict which "task_struct" will pick up the
connection/datagram. Nobody can predict it. Even security_socket_accept()
and security_socket_recvmsg() can't predict it.

If TOMOYO is allowed to make policy decisions based on the "task_struct" who
picks up the connection/datagram, the only possible approach is to introduce
security_socket_post_accept() and security_socket_post_recv_datagram().
--
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