• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: macnetworkprog digest, Vol 3 #511 - 13 msgs
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: macnetworkprog digest, Vol 3 #511 - 13 msgs


  • Subject: Re: macnetworkprog digest, Vol 3 #511 - 13 msgs
  • From: Joshua Graessley <email@hidden>
  • Date: Wed, 3 Sep 2003 11:10:28 -0700

On Sep 2, 2003, at 11:59 PM, Ryan McGann wrote:

Yes, for the best security possible a customer needs to buy one of (our) gateway products that includes IDS, firewall, spam filtering and AntiVirus file scanning on inbound and outbound email in a hardware box protected by several security measures including SmartCard and password protection. But convincing Mac users to buy security products is hard enough. Personal Firewalls are not meant to protect computer labs or places where secure access to the terminal cannot be guaranteed, but they work fine in a home environment.

I'm not suggesting that everyone should buy a firewall. My point is that a personal firewall is worse than no firewall. Developers constantly ask about how they can figure out if their product will work when the personal firewall is enabled. This implies that a personal firewall breaks legitimate products. It is not clear that any benefit is derived from having a personal firewall.

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.

Applications wouldn't need to worry about whether or not they would work. If the user didn't authenticate the process, the function could return EPERM. We wouldn't have to come up with elaborate rules to try and decide what traffic is okay and what traffic is malicious.

-josh
_______________________________________________
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.

  • Follow-Ups:
    • Re: macnetworkprog digest, Vol 3 #511 - 13 msgs
      • From: Wade Tregaskis <email@hidden>
    • A different kind of firewall
      • From: "Peter Sichel" <email@hidden>
References: 
 >Re: macnetworkprog digest, Vol 3 #511 - 13 msgs (From: Ryan McGann <email@hidden>)

  • Prev by Date: RE: Panther and Firewall API?
  • Next by Date: RE: Panther and Firewall API?
  • Previous by thread: Re: macnetworkprog digest, Vol 3 #511 - 13 msgs
  • Next by thread: A different kind of firewall
  • Index(es):
    • Date
    • Thread