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:	Tue, 21 Apr 2009 23:34:03 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	greg@...kko.com
Cc:	penguin-kernel@...ove.sakura.ne.jp, 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().

From: Greg Lindahl <greg@...kko.com>
Date: Tue, 21 Apr 2009 23:10:06 -0700

> On Tue, Apr 21, 2009 at 09:23:42PM -0700, David Miller wrote:
> 
>> I said explicitly that hard errors are allows (out of file
>> descriptors, memory allocation failure)
> 
> I have no idea what you meant by a "hard" error. Note that I also
> discussed EAGAIN, which appears to happen commonly historically and
> today, and appears to be what the security module folks would want to
> have happen and you're rejecting. Do you consider that to be a hard
> error? I'm betting not.

People use poll() to avoid -EAGAIN and blocking, they expect the bits
to tell them what fd's they can work on to do real work.

But this whole task_struct based security is bogus from the start.

If I dup a file descriptor for a listening socket, and accept() in the
"wrong" task, the other task has no way to accept() that connection
even if it's security settings allow it.  The connection is lost
forever.

The realm of file descriptors overlaps that of tasks.  Trying to
pretend this isn't the case results in all kinds of crazy things like
we see being attempted here.

I consider TOMOYO conceptually broken in many regards.
--
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