On Thursday, July 5 2007 10:01:59 pm Tetsuo Handa wrote:
> Paul Moore wrote:
> > I believe the existing security_inet_conn_request() LSM hook should allow
> > you to do what you want.  Adding another hook _after_ the inbound
> > connection has been accepted is probably a bad idea.
>
> Unfortunately, security_inet_conn_request() doesn't allow blocking
> operation. I want to sleep inside this hook because I want to use
> interactive operation by asking users whether to accept this connection or
> not.

Perhaps you could move the security_post_accept() hook further up and add a 
return value?  I do not see any current in-tree users of the hook and I 
imagine moving it up would actually make the existing hook a bit more useful 
in general.

> > Is there some reason why you can't use security_socket_recvmsg()?  Also,
> > don't forget that there are many other ways to read a network socket than
> > just recvmsg().
>
> security_socket_recvmsg() is called before retrieving a message.
> I want a hook that is called after retrieving a message
> because I want to use IP address and port number.
> But it seems that there are cases (recvmsg() and read()?) where
> __sock_recvmsg() is called with msg->name == NULL and msg->msg_namelen == 0
> that makes what I want to do impossible.
> To make IP address and port number always available,
> some more changes (that are not related with LSM) are needed.

In the existing security_socket_recvmsg() hook you could peek at the top of 
the socket's receive queue and determine all of the information you would 
want to know to make your access decision.  Granted, it still might be a bit 
racy if you have two threads reading from the same socket (maybe there is a 
lock there, I would have to check it further) but it can't be any worse then 
performing an access check _after_ the fact ...

-- 
paul moore
linux security @ hp
-
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to