Re: software firewall wishlist (pf, but see systrace, which was a good idea, too)
Re: software firewall wishlist (pf, but see systrace, which was a good idea, too)
- Subject: Re: software firewall wishlist (pf, but see systrace, which was a good idea, too)
- From: "Christopher D. Lewis" <email@hidden>
- Date: Wed, 17 May 2006 13:43:15 -0500
On Apr 3, 2006, at 10:12 PM, Terry Lambert wrote:
On Apr 1, 2006, at 12:52 AM, Jett Tayer wrote:
Hi,
I wish pf or ipfilter be ported to darwin so we
will have choices for better firewalls (ipfw, pf, ipf)
OT: ipfilter now runs on linux
You might want to try "man ipfw"; you are running Tiger, right? 8-).
For pf and ipfilter, either one could be ported as an NKE (Network
Kernel Extension) pretty trivially, and Apple provides NKE sample
code already.
To get all the things the pf tools support (including firewall
failover, load balancing, packet prioritization, per-user port access
privileges, network address translation, and the like) there's a host
of userland stuff that'd need porting (and the .kext would need to
create pf's virtual devices, so userland apps could interact with the
firewall as the developers intended). (Note that pf does both NAT
and packet filtering, so the pf port would involve more than the
firewall's .kext and userland, it would involve removing the stuff
that collides with pf's other functions.) FreeBSD has a pf port, and
pf has apparently been part of the FreeBSD 5.x tree since sometime in
2004, though I don't know the size of it's user base. The fact that
pf is under active development, has actual analysis of packet numbers
rather than brainless trust of packet flags as its indicator of
existing states, and supports things like fail-over make it very
attractive for people who really want to run firewalls (e.g., need
extremely large bandwidth filtered reliably and without losing either
protection or connection during upgrades). The fact that the tools
are being ported to FreeBSD suggest a more likely route of entry to
the Darwin code base than requesting a port directly to Darwin, given
the last response to inquiries about Darwin's firewall and its
possible replacements. For pf see http://www.openbsd.org/faq/pf/
index.html Note that pf allows (via authpf) exposure of different
firewall rules to different users, which is a great way to expose
intranet assets to traveling members of an organization; simply
require users to authenticate by remote login and presto, they get
access to ports that give the restricted material. If you don't like
your server logs filling with attacks, firewall everybody who can't
authenticate on port 22 and your server will be saved the overhead of
establishing SSL sessions with attackers.
From my reading on the relative (de)merits of various firewalls, my
favorite champion for a robust and administrator-friendly firewall
solution is pf. Quite aside from the actual behavior of the various
solutions out there, pf has the added advantages of (a) a BSD license
and (b) introduction into a code tree from which Darwin periodically
obtains updates anyway. If pf can be made part of the code import,
it will be a bit more future proof than some of the lost security
improvements such as Systrace.
The history of Systrace (which in an earlier version of Darwin
allowed fine-grained privilege control, privilege escalation, etc.;
trojans would have a hard time screwing with a system running such an
environment; alas, Apple's compile didn't include this Darwin code)
in the Darwin kernel is a sad one. Systrace was not part of a code
base Apple could update from FreBSD and thus died from nonsupport
when its creator lost access to a machine that ran Apple's operating
system. Also, nobody at Apple seemed to "get" what it did or why it
was good for the average user (heck, the onboard firewall is shipped
off by default too; people enable and configure at their own
peril). Without actually trying systrace, some folks alleged on this
list that it would make their machines unusable by Grandma (which is
why the firewall ships off by default, no?). Screen shots of iTunes
running under Systrace http://www.citi.umich.edu/u/provos/systrace/
macosx.html indicate both that a GUI front-end can offer user-
friendly management and that "traditional" MacOS apps can work just
fine under Systrace (while being barred from doing anything not
allowed, and without requiring the application to be re-written to
take advantage of fine-grained capabilities; imagine running a
system without needing setuid apps and other security risks, eh? And
what a way to cage Trojans without needing jails, eh?). While I'm
talking up Systrace, it's worth pointing out that applications'
installation frequently requires users to enter admin passwords but
don't provide much help in determining what behavior will follow the
entry of the password; having installation reveal the vendor-
suggested systrace policy requested by the installed app would
significantly improve users' understanding of what the app plans to
do (e.g., a MSFT word processor that opens network ports at launch,
etc.). An admin tool like Systrace, even if like the firewall is
shipped in a passive state, would give users with security concerns a
real advantage. MacOS X may not have viruses, but protection against
Trojans would be great, eh? And developing systrace policies can be
done by a userland program that watches the system calls target apps
make. http://www.onlamp.com/pub/a/bsd/2003/02/27/
Big_Scary_Daemons.html I'd like to ship the developer a machine from
which to revitalize the systrace code, but I'm concerned that his
work may be ignored.
But I digress. In short, fine-grained privilege management and
privilege escalation and so on may be more readily available through
Systrace than it may down the road from TrustedBSD; and systrace,
because it doesn't require applications to know about the kernel's
policies, won't break apps that outlive a particular version of
systrace. Since apps don't need to know about Systrace for the
system to benefit from systrace when running the apps, it adds no
burden on third-party developers (unless they want to ship proposed
systrace policies for the convenience of folks who activate it).
Where is the place to ask what sort of support would be needed for a
security technology like this to be included in Darwin as something
Apple actually compiles, and not merely tolerates sitting unused in
the Darwin code tree?
Sorry about the length. The original answer seemed to make it sound
like a pf port would be a .kext project, when it's a carefully
integrated system of kernel and userland tools that offer
functionality that includes functionality of projects larger than
those of the packet filter one would replace. The real question
seems to be, if security improvements were offered to Apple would
Apple ignore them or now? The pf code (kernel and userland) is in
use in FreeBSD and available now; if someone took the time to
package it up for Darwin would it even be accepted? Would it be
treated like Systrace and ignored? Does Apple's evolving interest in
security change its previously-likely behavior? (e.g., its previous
hostility to the very idea developers in the BSD community would
bother to make *another* firewall, and *why* would anybody so waste
their time? Literally, that was emailed to me from an address
@apple.com) I'd like to see improvements to Darwin (for desktop and
for server environments) but I'm hesitant now to give real support to
efforts to provide code.
Any thoughts?
Many thanks,
Chris
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden