On Tue, 2009-01-20 at 15:47 -0500, Paul Moore wrote:
quoted text
> Another option that was brought up (although perhaps not very clearly 
> since it isn't listed here) was the embedding of the personal firewall 
> hooks into the individual LSMs roughly similar to how capabilities are 
> handled with SELinux today (a separate security mechanism that has 
> explicit calls within SELinux).  This approach enables the use of 
> current LSMs (although minor modifications will be needed) and avoids 
> the need to add new hooks to the core network stack.

Sorry for not adding that one, I think you sent that email after I
finished writing the summary and that's why it wasn't included in the
first place.
This is another way of doing it, yes, but in the end we would probably
end up writing additional wrapper like code with the only purpose of
being called by <insert favorite LSM here> and then forwarding that call
to <insert favorite personal firewall here>.
To have multiple approaches working we would probably need
register/unregister functions for that wrapper and, to be honest, to me
this sounds like a more complicated version of doing the calls to the
wrapper directly from net/socket.c. The outcome is pretty much the same
though.

quoted text
> > What has not been agreed on yet is whether only a way of hooking
> > these calls should be made available to implementations or whether
> > the whole in-kernel part should be developed together and allow
> > implementations of personal firewalls in userspace only, for example
> > using a netlink socket to communicate with the shared in-kernel code.
> 
> Since there will always be a significant userspace component to any 
> personal firewall approach it seems reasonable to push the decision 
> making into userspace and leave the kernel component relatively simple.  
> The basic idea behind Samir's "snet" concept where the kernel simply 
> passes messages to userspace and waits for a verdict seems like a 
> reasonable approach in that it can be made to support different 
> personal firewall implementations/designs without significant changes 
> to the kernel.

I can only agree on that. However, providing a single solution that
cannot be extended dynamically (think of adding support for additional
protocols, implementing some sort of policy caching, etc.) might be the
wrong way to go.
We would end up having a solution and whilst I really like the snet
approach we would lose some flexibility.
This very approach on the other hand seems to work very well for
netfilter and we would end up with keeping all those personal firewall
developers out of the kernel.

-- Stephan

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html