Using Systems/Network Extension in Command Line Tool app

Wanted to see if its possible to utilise the Network Extensions API on a command line tool application.

I am aware of the Simple Firewall project and it prompts the user to enable System Extensions in the security panel, can this behaviour be done on a Command Line Application ?

My objective is to design a CLI app similar to htop to monitor network bandwidth usage per process. Kind of like nettop

Thanks in advance, hoping for a swift reply.

Replies

It looks like I may have answered your question already out on this thread. Please respond back if my previous response does not cover your question.


Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
@Matt, thanks for the reply. I saw that thread and my initial query has been solved. However can you help with some additional questions.

As per my understanding, when you deploy a network extension via a container app, you get two prompts of notification.

One is to "Install" the system extensions and the second is to allow the user to run the "Network Capability" contained in the extension.

this is by design to let the user know that some system extension has been installed. I read somewhere that during an install by MDM, you can bypass the second segment I mentioned above. Correct me if I'm wrong but the first part (i.e. the install) cannot be bypassed by any means. A user has to select allow as a prompt.

My second question is, is it possible to deploy a system extensions contained in .pkg file, instead of an .app ? Lets say I have system extension and a command line tool app enclosed in a .pkg file. Is it possible to totally forgo the requirement of an .app to deploy this ?

Thirdly, can the Network Extensions API collect bytes sent/bytes recieved per process ? My understanding of this API is rusty at best atm, but if I was to try, I would imagine an application layer proxy could capture this information and instead of blocking/allow, like in the SimpleFirewall example, we would simply allow but keep track of all the bytes sent/recieved. My endgoal is something similar to Network tab in Activity monitor.

this is by design to let the user know that some system extension has been installed. I
read somewhere that during an install by MDM, you can bypass the second segment I
mentioned above. Correct me if I'm wrong but the first part (i.e. the install) cannot be
bypassed by any means. A user has to select allow as a prompt.

Using MDM you can auto-allow the prompt for a Network System Extension using this profile specific payload. The prompt to allow the Network Configuration cannot be auto-approved unless you are using specific conditions for a WebContentFilter. The second prompt should also be displayed to the user so they understand the Network Configuration being installed on their system.

My second question is, is it possible to deploy a system extensions contained in .pkg
file, instead of an .app

I am going to approach this from an MDM scenario since you mentioned MDM above; A typical workflow here would be to build and sign your container app with a Developer ID identity. This container app would contain your Network System extension. From there, create a pkg installer that contains your container app project, then Developer ID sign and Notarize that pkg file for distribution.

Thirdly, can the Network Extensions API collect bytes sent/bytes recieved per process ?
My understanding of this API is rusty at best atm, but if I was to try, I would imagine
an application layer proxy could capture this information and instead of blocking/allow,
like in the SimpleFirewall example, we would simply allow but keep track of all the
bytes sent/recieved. My endgoal is something similar to Network tab in Activity monitor.

If your goal is to keep track of all of the network bytes passing through a proxy, technically there is nothing stopping you here. However, this would assume you are handling all of the connections, in some cases this could incur a performance penalty, and is probably consider an off-label usage of these APIs.


Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com