netdev - Re: [PATCH] LSM: Add security_socket_post_accept() andsecurity_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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 24 Apr 2009 22:57:27 +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, greg@...kko.com
Subject: Re: [PATCH] LSM: Add security_socket_post_accept() andsecurity_socket_post_recv_datagram().

David Miller wrote:
> Are you beginning to understand the fundamental problems I have with
> your work?
You are saying that we must not discard what we have in the queue after we told
somebody that we have something in the queue unless we get "hard" errors.

> If poll() says to a listening socket that connections are
> available, we MUST return a connection from accept() unless
> there is a hard error.
I haven't understood what you meant by a "hard" error. What I want to know is,
are errors returned by security_socket_accept() and security_socket_recvmsg()
"hard" errors?

If these errors are not "hard" errors, security_socket_accept() and
security_socket_recvmsg() must not return an error because it will result in
"not returning a connection/datagram", for you are saying that only "hard"
errors can justify "not returning a connection/datagram".

If these errors are "hard" errors, security_socket_accept() and
security_socket_recvmsg() can justify "not returning a connection/datagram".
But errors by newsock->ops->getname() or move_addr_to_user() (these are also
"hard" errors, aren't they?) justified "discarding a connection/datagram".
Then, if a "hard" error was returned by LSM hooks after a connection/datagram
was dequeued, I think we can justify "discarding that connection/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