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]

Message-Id: <200709040753.32204.paul.moore@hp.com>
Date:	Tue, 4 Sep 2007 07:53:31 -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 Monday 03 September 2007 9:15:27 am Tetsuo Handa wrote:
> Hello.

Hi.

> Paul Moore wrote:
> > 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.
>
> When I proposed a patch in July, I was patching at post-copy_to_user() step
> (i.e. after sock_recvmsg()).
> This approach messed up user-supplied buffer.
>
> This time, I'm patching at pre-copy_to_user() step
> (i.e. at skb_recv_datagram()).
> This approach doesn't mess up user-supplied buffer.
> I think this is a cleaner way than the previous patch.

It might be cleaner than your previous patch but it ignores some of the more 
important points that were brought up by the community in previous 
discussions.

> Although read() gets an error when select() said "read ready",
> I can't find other place to use for accomplishing my goals.
>
> By the way, similar thing can happen when select() against
> a file descriptor said "read ready" but read() gets an error
> if security policy or security-id of the file has changed
> between select() and read(), isn't it?
> And such behavior is acceptable, isn't it?
> If such behavior can happen and is acceptable and *preferable*,
> I think checking permission at dequeue time (i.e. skb_recv_datagram())
> is *preferable* way than checking permission at enqueue time
> (i.e. socket_sock_rcv_skb()).

As mentioned before that problem with enforcing access control at "dequeue" 
time is that the system has already accepted the packet from the remote 
host - how do you plan to deal with these unacceptable/bad packets sitting on 
a socket, waiting to be read by a process which does not have access to them?  
What about connection oriented sockets where the remote host will assume 
everything is okay and continue blasting the machine with more, illegal 
packets?  If you aren't going to allow the socket/application to read the 
packet, never allow the system to accept it in the first place.

The *preferable* solution, as previously stated before by several people, is 
to investigate other access control methods like the netfilter userspace 
queue mechanism.  At the very least, please explain how the approaches we 
proposed will not accomplish what you require.

-- 
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/