netdev - Re: [PATCH] LSM: Add post recvmsg() hook.

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] [day] [month] [year] [list]

Message-Id: <201007232137.DJD12929.JOMFFtSQLVOOFH@I-love.SAKURA.ne.jp>
Date:	Fri, 23 Jul 2010 21:37:22 +0900
From:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To:	davem@...emloft.net
Cc:	kuznet@....inr.ac.ru, pekkas@...core.fi, jmorris@...ei.org,
	yoshfuji@...ux-ipv6.org, kaber@...sh.net, paul.moore@...com,
	netdev@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: [PATCH] LSM: Add post recvmsg() hook.

David Miller wrote:
> The fact is going to remain that you will be unable to return data
> from recvmsg() to a blocking socket when ->poll() returns true even
> though data is in fact there in the socket receive queue.
> 
Maybe I misunderstood here.

Are you worrying that TOMOYO will no longer be able to deliver remaining
packets in a receive queue once a packet from address/port which is not
permitted to pick up reached the head of the receive queue?
(Please answer "yes" or "no" here.)

If your answer is "yes", I tolerate the side effect (i.e. applications have to
close and recreate the socket in order to resume receiving packets).
My preferred behavior is to drop the packet but you will not accept it.
I accept not to drop the packet if you can accept security_socket_pre_recvmsg().

If your answer is "no", let me restart from reconfirming requirements which
LSM hook for recvmsg() must satisfy, before continuing discussion on
security_socket_pre_recvmsg() hook.
--
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