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

Date:	Wed, 21 Jul 2010 21:06:36 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	penguin-kernel@...ove.SAKURA.ne.jp
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.

Your analysis is wrong, and what Tomoyo is doing is so fundamentally
different than what the existing SELINUX hooks do.

The existing LSM hooks do not break BSD socket behavior.  Do you know
why?  Because someone who understood all of this spent a great deal
of time carefully designing them.

The existing hooks do not drop packets on recvmsg() when a security
check does not pass, they signal the error long before the socket
receive queue is even looked at.  It is just like seeing a -EFAULT,
-ENFILE, or similar error.

Checks are always made _BEFORE_ major state changes are made to the
socket.

That is critically important, and it's what you seem to fail to see.

The hooks you propose _LOSE_ information.  So even if another process
has the 'fd' for a socket, and they would be allowed to receive the
packet by LSM checks, the post hook does not allow that to happen
because the failing 'fd' just frees up the packet and loses it
forever.

The existing hooks signal before we pull the new connection out of the
accept queue during accept(), therefore avoiding the illegal situation
your post ->accept() hook would create since there is absolutely no
way (and there should not be a way) to push a connection back into the
sock accept queue after we've taken it from the protocol layer.

And again here, the proposed hooks _LOSE_ information.  The accepted
connection is lost forever, another process with valid security
credentials cannot accept the connection.  It is completely gone.

And I'm not even going to entertain adding facilities to allow pushing
things back into the socket state after they've been removed for
inspection.

I think we've been through this issue enough times that we have covered
the issues in their entirety, and nothing you have written convinces
me that my position is wrong and that it is valid to put the Tomoyo
post-recvmsg and post-accept hooks into the tree.

Sorry, but I'm not applying your patches, they are fundamentally flawed
unlike the existing hooks.
--
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