Re: Socket filtering
Re: Socket filtering
- Subject: Re: Socket filtering
- From: Terry Lambert <email@hidden>
- Date: Wed, 26 Apr 2006 19:05:18 -0700
Unless it was a notification from something like:
shutdown(s,SHUT_WR);
(Not that I think that's likely). In that case, the local client
would expect to still get data, but not send it. That probably
wouldn't do what he thinks he wants, though -- the problem is that you
could get an infinite amount of data after that, and it might include
the data you don't want to get through, so you can't just flush the
packet on out.
If he's just monitoring data content, though, he should make a local
copy for however big his buffer size is, and just let it through,
unless he's trying to catch bad data before it gets in, and wants to
check data spanning a buffer boundary, rather than just monitoring.
But if the buffer that was swallowed doesn't itself contain the data
you're trying to stop, then sending a partial buffer, and keeping a
local copy in the kext for the spanning check, rather than swallowing
it, is still an OK thing to do (assuming the data isn't malicious
unless complete - and if it's malicious when incomplete, then the
check should have matched already on the packet that was swallowed.
I expect that sending it on would be his way of discarding the buffer
without having to actually do the necessary record keeping (just
expecting the socket close code to do it for him, instead).
If that's the case, then the issue is a race - and what he needs to do
is a notification interlock on the close, so that the data gets
propagated or dropped - if not by the close of the socket, then by
himself. Otherwise he might end up with a slow leak, especially if
his pattern matching is pretty slow.
-- Terry
On Apr 26, 2006, at 6:23 PM, Ronnie Misra wrote:
Perhaps the client is closing the socket because they time out
waiting for the packet that you've swallowed? Anyway, as Mike points
out, once the client has decided to close the socket, you're too
late. And there is nothing the system could do to warn you before
the client makes the decision to close the socket...
Ronnie
On Apr 26, 2006, at 5:46 PM, Michael Smith wrote:
On Apr 26, 2006, at 4:49 PM, Eric Long wrote:
You are asking for a hook to use as a warning that the socket will
close. Do you mean a hook before the client calls close on the
socket? I'm not sure how one would predict such a thing. A hook
after
the client calls close seems useless because the client is done
calling read, so there is no point in injecting data.
Well, I'm scanning data looking for pattern matches. I don't
necessarily
know the protocol, so I don't know for sure how much data to
expect. If I
find a partial match in a packet, I want to see if the next packet
contains
the end of the data I am looking for, so I swallow the packet and
wait for
the next packet. If it turns out there is no next packet, I've
got a
problem. If I discard the data, I've messed up the stream. I
need to
properly reinject it before the socket closes.
Why? The socket is closing, nobody will ever read the data. Just
throw it away; that's all the system would do if you were to
reinject it anyway...
= Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden