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]

Date:	Wed, 22 Apr 2009 09:55:26 +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:
> If poll() says to a listening socket that connections are
> available, we MUST return a connection from accept() unless
> there is a hard error.

No application is permitted to assume that accept() returns a connection if
poll() says that connections are available even if there is an assumption that
none of sock->ops->accept(), newsock->ops->getname(), move_addr_to_user()
fails, for there is security_socket_accept() hook which can interrupt between
"poll()" and "accept()".

There is a possibility that LSM module's policy changes from "allow picking
the connection up from the listening socket" to "deny picking the connection
up from the listening socket" after poll() said "connections are available".
We allow this policy change and we tolerate breakage of the application
expected semantics.

> If we tell the application, via poll() or similar, that connections
> are available and no other thread can get in there to steal the
> connection, we must deliver a connection to the listening socket when
> it calls accept() except in very unusual circumstances (out of file
> descriptors, memory allocation failure, etc.)!

If you think policy changes between poll() and security_socket_accept() is
one of unusual circumstances, I think policy changes between
security_socket_accept() and security_socket_post_accept()
(the old policy before poll() said "connections are available" was "allow
picking the connection up from any client" while the new policy after
poll() said "connections are available" is "allow picking the connection
up from only 127.0.0.1") is also one of unusual circumstances.
The only difference between security_socket_accept() and
security_socket_post_accept() is that whether the connection remains in the
listening socket's queue or not. We cannot avoid breakage of the application
expected semantics from the beginning.
--
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