linux-kernel - Re: [TOMOYO 15/15] LSM expansion for TOMOYO Linux.

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, 28 Aug 2007 09:21:48 -0400
From:	Paul Moore <paul.moore@...com>
To:	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc:	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, chrisw@...s-sol.org
Subject: Re: [TOMOYO 15/15] LSM expansion for TOMOYO Linux.

On Tuesday, August 28 2007 6:39:13 am Tetsuo Handa wrote:
> Hello.

Hello.

> Paul Moore wrote:
> > >    * post_recv_datagram is added in skb_recv_datagram.
> >
> > Can you explain to me why this is not possible using the existing
> > security_socket_sock_rcv_skb() LSM hook?
>
> socket_sock_rcv_skb() is a hook for enqueue time.
> I want a hook for dequeue time, because what TOMOYO Linux is doing is
> not "whether a socket created by foo is permitted to pick up
> an incoming packet from specific address/port"
> but "whether bar is permitted to pick up
> an incoming packet from specific address/port".
> At the time of enqueue, I can't know who will pick up that packet.
>
> Same reason for socket_post_accept(). What TOMOYO Linux is doing is
> not "whether a socket created by foo is permitted to accept
> a connection request from specific address/port"
> but "whether bar is permitted to accept
> a connection request from specific address/port".
> At the time of enqueue, I can't know who will pick up that request.

I apologize for not recognizing your approach from our earlier discussion on 
the LSM mailing list in July.  Unfortunately, I have the same objections to 
these changes that I did back then and from what I can recall of the 
discussion the rest of the kernel networking community agreed that these 
changes are not the preferred way of solving this problem.  We offered 
suggestions on how to accomplish your goals in a way that would be acceptable 
upstream and I would encourage you to investigate those options further.

-- 
paul moore
linux security @ hp
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/