site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Apr 27, 2006, at 10:14 , Eric Long wrote: 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. If I knew there was no more data to come, I wouldn't want to hold the packet. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large, Director Institute for the Enhancement of the Director's Income -------- The path of least resistance: it's not just for electricity any more. -------- _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... That's a bit broad of an assumption. The previous packet might have just a couple of bytes that match. It's hard to say how much data is quantitatively malicious if its sensitive data. I can thwart a transaction when I know I've matched a pattern I'm looking for, but if I don't hold packets, a partial data transfer might actually be detrimental. I'm scanning streams that other processes are conducting using an NKE socket filter. If I swallow a packet it is only intended to be temporary, until I can either get more data and determine to reinsert it based on the new data or arbitrarily set a timeout to reinsert it if no more data was received. But if the socket closes and I don't get the data back into the stream before that, the transaction ends up incomplete and its my fault. I swallowed the packet only because I found a partial match at the end of its data holding out the possibility that more data was coming that might demonstrate a true match. A few observations: - if the underlying protocol is stream-based (like TCP), you will see a packet terminating the connection, coming from the local endpoint. You won't know whether this packet is "graceful" or "prejudicial" :-} If "graceful", you should push the data out; otherwise, not. Oh, and not all stream protocols distinguish (leaving it to higher layers to complete a handshake to terminate). - if the underlying protocol is datagram-based, you are hosed. It is possible that the local endpoint-owner will call a "disconnect" procedure for the socket, but that need not translate into a real packet. Even if there is a "hook" to give you control in this case, most UDP- spewers don't do it, so the only way you know that there aren't any more packets coming is that there aren't any more packets coming :-} In short, for real streams, you can fake it by looking for terminating (e.g., FIN) packets. Otherwise, you have no idea what comes next, or when. It also occurs to me that by holding onto a packet, waiting for "the next one", you are screwing around with the transport's idea of timing, and potentially harming the connection, and perhaps the data it carries. Just keeping a copy of the current packet and pushing the packet out doesn't seem like what you want (unless you just want to see what passes by), so it's not clear to me how to get the 100% solution... This email sent to site_archiver@lists.apple.com