Hello. Paul Moore wrote: > 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? If netfilter hooks allow blocking operation, it may be a solution. But making decisions at send()/recv()/connect()/accept() time is enough because my purpose is not "keep away userland from reaching unwanted message" but "keep away userland from processing unwanted messages". I tolerate reaching unwanted message to userland if userland doesn't process it. My plan is "drop IP spoofing messages and/or messages that nobody wants using netfilter hooks and then drop messages that are unwanted for that application using security_socket_post_recvmsg() hook".
I think telling the application a fake result (as if there are no messages available) after dequing this message requires minimal changes to the kernel and has little damage to the application. Some application might assume that supplied buffer is not modified if recv() returns an error, but it is not guaranteed because recv() returns -EFAULT or something (if move_addr_to_user() fails) without recovering supplied buffer. So, recv() returning -EPERM after dequing this message is acceptable? - 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
