site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=KOK7Htb80Tk8MEiPgj5mgC3ZffLx2C7N1Fdsxy3Y9GTlZUekLSzvGNbKxz0LS02X; h=Received:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Hi, I wish pf or ipfilter be ported to darwin so we will have choices for better firewalls (ipfw, pf, ipf) You might want to try "man ipfw"; you are running Tiger, right? 8-). Any thoughts? Many thanks, Chris _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... On Apr 3, 2006, at 10:12 PM, Terry Lambert wrote: On Apr 1, 2006, at 12:52 AM, Jett Tayer wrote: OT: ipfilter now runs on linux 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. This email sent to site_archiver@lists.apple.com