Re(2): Browser filtering
Re(2): Browser filtering
- Subject: Re(2): Browser filtering
- From: Peter Lovell <email@hidden>
- Date: Thu, 09 Dec 2010 21:15:19 -0500
On Thu, Dec 9, 2010, eveningnick eveningnick <email@hidden> wrote:
>Hello, Quinn
>Thanks a lot for conspicuous answers!
>
>> IMO this is a two horse race between a socket filter NKE and ipfw. In
>your situation I'd go with a socket filter, but I have lots of kernel
>programming experience (-:
>
>What kind of NKE filter would you choose in my case? Would it be
>Socket Filter, or IP filter? The former as i understand, is easier to
>implement, but an instance of it will be allocated for every new
>opened socket. The latter will be one for an interface, which reduces
>the waste of system resources but i am faced with more "raw" data.
>What would you suggest?
>
>Also i am wondering, what is Apple-suggested practice for
>"security"-oriented applications, like this one. Where it is more
>likely to place binaries - control UI application, launchd daemon
>(which loads kext), and kext itself? I am thinking about having a
>bundle, which user copies to applications. That bundle in its
>/Contents/MacOS/ contains ControlPanel of my app. Somewhere in
>/Contents/HelperTools it has a daemon's binary and and an NKE kext.
>This kext has to have a root:wheel owner, and 755-access rights, which
>should be explicitly set somehow - by ControlPanel, being launched
>first time (it should become root's itself, to be able to set these
>permissions), or by installation script (what is the best practice for
>drivers?).
>The bundle can be moved to trash accidently (or intentionally), but
>the driver will remain in memory, and launchd will think that the
>driver-launching daemon is still in
>/Application/Contents/HelperTools/, throwing every 10 seconds an alert
>on next system boot. Should i provide an uninstaller, or should i
>track the system event of moving the bundle to trash and remove the
>launching daemon'splist together with unloading the kext from memory?
>
>It's my first time trying to develop a driver, i'd like to know how
>things are done by experienced people :)
>Thanks again!
Hi Nick,
let me add a few comments to Quinn's excellent suggestions.
You will need a socket filter because it makes sense to deal with stuff
at that level.
There is only one instance of the NKE and *all* sockets go through it,
at least initially. You can choose for certain sockets to no longer pass
through your NKE, but they all knock on your door to start with.
Your NKE deals with all sockets, from all users. Remember that daemon
processes also do things and your NKE must be nice to them - not
everything comes from the logged-in user.
There might be other NKEs operating in there also. Even with several, it
all works well as long as everyone plays nice (there were some rogues in
the past).
If you want to make connection decisions based on DNS name then you need
to track the DNS requests and remember the addresses so that you can
match when a "connect" occurs. It's by address and not by name, of course.
The kext can't be located in your bundle so it isn't subject to being
accidentally moved to trash. Your bundle probably will have a copy of
the kext that can be used to repair a damaged-install, but doing the
repair will of course require the help of an administrator. I suggest
that you use the standard Installer to get all your pieces installed
properly. Many apps can be moved to trash for uninstall but yours has
privilege-install pieces so you should supply an uninstaller. It's
possible to craft your privileged pieces to notice that their owner has
gone away and so remove themselves, but that is an unusual level of
sophistication (and hard to debug well)
Cheers.....Peter
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden