Getting socket creation notification.

I've got a firewall configured using

pfctl

, and I'd like get notification if my configuration wasn't overridden.

I’m confused. PF is a system-wide service and, as far as I know, there’s no way that a socket can opt out of it. Did I miss something here? What’s the opt out mechanism that you’re concerned about here?

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I need to find a way to check that no entity sent different configuration to packet filter.

In such case, which is legal of course, I wish to send a proper notification to my application, to notify the user about it.

My filtering is based on ip and port in tcp/udp protocol, so I assumed that no socket can be opened if it contradict the rules in packet filter.

I especially refer to the following fields inside socket structure :

in_port_t sin_port;

struct in_addr sin_addr;

So I figured out that if I get notification that new socket created, I could match these values to my configured set of rules and If I find contradiction, and send the alert.

Unfortunately, according to what your say, it wouldn't work. Perhaps you can suggest an alternative approach ? P.S. I prefer to get a notification rather then perform periodical check of such scenario. Thanks !

Before we go further I’d like to ask about how you intend to deploy your product. Is this a ‘shrink wrap’ product intended to ship to a large number of users? Or something that you deploy internally to a small number of machines?

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

This firewall is a new feature for a product that intended to both small and large scale environments. It assume no MDM profiles are installed and is controlled from remote cross-platform management entity. Right now I'm doing some research about the possibility to add the firewall capabilities.

The problem with using PF in a firewall product is that there’s no documented scheme for rule arbitration between different products, and indeed the system itself. Thus:

• PF is completely inappropriate for a ‘shrink wrap’ product because the user might install a second product, or enable a system feature, that sets up conflicting PF rules.

• PF is OK to use in a managed environment because the site manager takes on the responsibility of avoiding conflicts.

In both cases you don’t need to worry about detecting conflicts. For a ‘shrink wrap products you shouldn’t be using PF in the first place, and for managed environments it’s reasonable to assume that conflicts won’t occur.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thanks for your valuable comment.

My managed environment doesn't prevent users with administrator right to install conflicting tools or modify the rules themselves directly using pfctl.

In that case, perhaps do you know of an alternative for managing rule arbitration and preferably have Cocoa based SDK rather than command-line tool.

So far I've checked NetworkExtension which doesn't have firewall capabilities in macOS and NKE that is deprecated.

My initial goal is pretty simple, just block all connections and than allow specific udp/tcp ports. thanks

My managed environment doesn't prevent users with administrator right to install conflicting tools or modify the rules themselves directly using

pfctl

.

Yeah, I was afraid that might be the case.

perhaps do you know of an alternative for managing rule arbitration

No. Such a system would likely have to come from Apple (in order to get all developers to agree to it) and that’s not something that Apple has tackled.

So far I've checked NetworkExtension which doesn't have firewall capabilities in macOS

Correct.

and NKE that is deprecated.

Not quite. We’ve announced that we plan to deprecate NKEs but we haven’t formally deprecated them yet because there are certain problems that can only be solved with an NKE. And building a firewall is one of those problems.

Right now you have to choose between two equally unpleasant alternatives:

• You can use PF and warn users about the potential for conflicts.

• You can build an NKE and accept that you’ll have to do significant work to deal with their future deprecation.

Regardless of what you choose, I encourage you to file an enhancement request requesting that the Network Extension framework provide better support for firewalls

If you decide to go down the NKE route:

• I recommend that you ***** a strong abstraction layer between the NKE-specific code and your core firewall code. This will make it easier to adapt when things change (it also has other benefits, for example, it’ll make testing easier).

• Deploying a KEXT requires special approval from Apple; see the Request a Kext Certificate section on the Developer ID page.

I wish that I had better news here.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Opened enhancement request No. 45189833.