On Friday, July 6 2007 10:59:49 am Tetsuo Handa wrote:
> > 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 ...
>
> I think dequeuing this message is needed, or programs that call recv() like
>
> while (1) {
> FD_SET(fd, &rfds);
> select(fd + 1, &rfds, NULL, NULL, NULL);
> recv(fd, buffer, sizeof(buffer), 0);
> }
>
> will begin meaningless infinite loop.
Okay, so remove the first message from the queue when your LSM declares a
denial.
> A proper way to avoid this loop will be "not to return ready answer for
> select()". But to do so, I will need modifications in lower layer where it
> is not allowed to sleep.
I'm not sure this would be the "proper" way to fix the problem, as you would
still collect data in the socket's receive buffer, you just wouldn't let the
application know about it. Thinking about the implementation also makes me
nervous as I can't think of a clean/sane way of doing it; maybe you can but
I'm still not sure that is justification for the change.
Thinking about your problem (personal firewall) a bit more I can't help but
wonder if your solution would be better implemented as a netfilter module?
Or maybe in userspace using the netfilter userspace queue feature?
--
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
