On Wed, Jan 21, 2009 at 8:52 AM, Samir Bellabes wrote:
> Paul Moore writes:
>> On Sunday 18 January 2009 11:17:28 pm Samir Bellabes wrote:
>>> hi lsm users,
>>> as the discussion thread "RFC: Socket MAC LSM" put a question on how
>>> to build a simple personnal firewall, I pleased to introduce the snet
>>> tool ...
>> Thanks for posting this, but as it stands right now I think we need a
>> bit more discussion before we pursue a personal firewall solution.
>> Regardless, I do like the approach you took of deferring the actual
>> decision processing to userspace; this should allow multiple personal
>> firewall implementations without the need for extensive kernel
>> modifications (make everyone's life easier).
> Yes, at first I wrote a daemon in userspace, responsive of dispatching
> the information to subsystems (logging, sending verdict, graphical tool
> to ask the user, database to check user rules rather than interactive
> ask, ..) but I finaly make the effort to build a library, which is
> easier for maintenance of the kernel part, and let the user build is own
Yes I am repeating myself. Why hook in the LSM. netfilter already
does outgoing packet blocking based on Process ID. Its not that hard
to expand it to application.
Expanding netfilter to do incoming would a performance boost. It
would be able to drop packets and even possible do other evils like
using layour 7i filtering to sort what application on X port gets the
packet. By the time you are to the socket point is too late for
incoming netfilter has already processed it. So if X application
should only allow packets from local applications but never from
external being at the socket level its displayed to everyone leading
to wasted processing at times.
Socket level is far limiting on what optimizations can be done. Same
foolishing of socket level makes putting complete filtering under
windows hard and costly on cpu time. Defining traffic zones in
netfilter is very effective.
To unsubscribe from this list: send the line "unsubscribe
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html