User: Password:
|
|
Subscribe / Log in / New account

Re: [RFC] snet - Security for NETwork syscalls

From:  Peter Dolding <oiaohm-AT-gmail.com>
To:  Samir Bellabes <sam-AT-synack.fr>
Subject:  Re: [RFC] snet - Security for NETwork syscalls
Date:  Wed, 21 Jan 2009 18:37:07 +1000
Message-ID:  <e7d8f83e0901210037l3f171f96md85d9eab5b30c944@mail.gmail.com>
Cc:  Paul Moore <paul.moore-AT-hp.com>, linux-security-module-AT-vger.kernel.org
Archive-link:  Article

On Wed, Jan 21, 2009 at 8:52 AM, Samir Bellabes <sam@synack.fr> wrote:
> Paul Moore <paul.moore@hp.com> 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 ...
>>
>> Hello,
>>
>> 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.
>
> sure
>
>> 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
> system.
>
> sam

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.

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



(Log in to post comments)


Copyright © 2009, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds