Re: macnetworkprog digest, Vol 3 #511 - 13 msgs
Re: macnetworkprog digest, Vol 3 #511 - 13 msgs
- Subject: Re: macnetworkprog digest, Vol 3 #511 - 13 msgs
- From: Wade Tregaskis <email@hidden>
- Date: Thu, 4 Sep 2003 09:05:18 +1000
It seems the right way to solve this problem is to use the
authorization framework and require authorization for operations such
as bind, connect, sendto, etc. Instead of filtering at the packet
layer on the local machine, which is fraught with problems, including
no feedback to applications, filter at the API layer. If a customer is
worried about traffic to and from their machine, a setting could be
modified to require authorization to open an outbound connection or
incoming connection. A user could choose to always allow certain
applications to perform these operations. The authorization framework
already has functionality for most of this. It wouldn't necessary
require typing a password, just the user accepting the applications
request to perform a network operation.
A better way of doing this would be for Apple to adopt systrace
officially into their binary distributed kernels. It allows you to
control access to any sort of system/library call, from any and all or
only particular apps. For example, you could have Apache setup so that
only binds to a certain port would be allowed, and read access only to
your web directory. And no write access, perhaps, except to an
appropriate logs folder and maybe some other locations where you need
to store data. Anyway, it's just an example.
The advantage of this is that you don't need any existing apps to
'update' to this new system; it's done transparently. If a call is
blocked, you can return whatever you like in it's place (most often an
appropriate error defined for that particular call).
You can install your own systrace'd kernel, without too much
difficulty, although the binary compatibility issues are a pain - the
Darwin 6.6 kernel doesn't properly match MacOS 10.2.6, so there are
some stability issues. Of course, if Apple simply included systrace
themselves, all these issues would just go away.
There's already a well developed interface to systrace, in the form of
config files, as well as a GUI helper which allows you to make
decisions in real time, as a particular application makes different
calls.
I know it sounds like I'm doing a sales pitch. I've been begging Apple
to look into systrace for months. I think they did/are, but there's
been no word on it as yet. Last I heard, they were trying to get
support for it in the form of developers requesting it. This seems
like a very good use for it.
Another advantage with systrace, particularly in the realm of
virii/system-exploits, is that Apple could issue a microscopic patch to
such things in the form of a systrace config file modification, e.g.
they could update Apache's config to disallow parameters beyond a
certain length to a particular function, if a buffer overflow is found
in that function. Just as an example.
Anyway, the systrace page is
<
http://www.citi.umich.edu/u/provos/systrace/>. While that page isn't
often updated, it's probably just because systrace is stable. Indeed,
it's already standard in several major Linux distro's, and I even
recall mention of it being in OpenBSD 5.0.
Wade Tregaskis
-- Sed quis custodiet ipsos custodes?
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.