Jonathan Day <imipak@xxxxxxxxx> writes: > --- On Tue, 1/20/09, Stephan Peijnik <stephan@xxxxxxxxxx> wrote: [...] >> This means personal firewalls should not enforce system >> security policy, >> but rather a per-user security policy. >> The implementations can then add caching of decisions made >> (ie. >> "remember this decision") and thus not ask every >> time a call is made. >> Also, the only protocols to be supported are IPv4 and IPv6. >> Adding >> support for AF_UNIX and/or AF_NETLINK doesn't make much >> sense, as this >> is not network-related and would only increase the amount >> of work a >> personal firewall implementation has to do. > > I agree that Unix and Netlink would not be useful, but there are other socket types that are LAN- or WAN-based, and I'd not be too quick to implement anything that precluded them being covered. (There's a difference between designing code in a way that makes extending it hard and actually implementing other network types, so only implementing IPv4 and IPv6 on a framework that could be extended by anyone deeply passionate about other protocls makes sense -- unless implementing it that way would be so much harder that it's pointless.) Exactly, and the cost for the kernel subsystem and the userspace low level part should only be adding the new elements for sending usefull informations to the userspace and wait for verdict, but the cost for the 'personnal firewall' developper is higher (how this protocol is interacting with others ? etc etc) >> All proposed implementations of personal firewalls until >> now have made >> it rather clear that the decision-making logic should be >> placed in >> userspace, whilst only a small piece of code communicating >> with a >> userspace daemon should be placed in the kernel itself. > > Well, it has probably not been a significant factor in anyone's decision, but it occurs to me that per-process firewalling within the kernel makes the "per-process" bit much more complicated and would not work at all using any of the zerocopy or kernel bypass networking mechanisms. we don't need this at all, as we are in process context, syscall can sleep. Trust me, it's strange to have it's web browser freezing waiting for a timeout if the userspace part doesn't reply, but if it's replying, it's transparent. sam -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
