Network Extension and Restrictive Sandbox

Question

Jon Gabilondo OP

Created Jun ’20

Replies 4

Boosts 0

Views 1.9k

Participants 2

Hi,

Playing with SimpleFirewall I wanted to access a file in Downloads folder. I could not open the file in Downloads for read. I tried the Group Container with the same result. I was applying my sandbox experience but I couldnt get a "regular sandbox" access behavior.

I found the explanation in https://developer.apple.com/documentation/networkextension/nefilterprovider

Because the Filter Data Provider extension has access to all of the network content flowing through the device, it runs in a very restrictive sandbox. The sandbox prevents the Filter Data Provider extension from moving network content outside of its address space by blocking all network access, IPC, and disk write operations.

I understand the reasoning but, I wanted to confirm if I'm left with no options at all to access any files outside the bundle. Not even in the Group container to exchange data with another process with the same goup ID ? How about connecting a UNIX domain socket, it is a FD, same resrictions ? XPC to another process (Not the Host App) with the same group ID ?

Does or will the ES Sysex have restrictive sandboxing as well ?

Thanks.

Boost

Answer 1

DTS Engineer OP

Apple

Jun ’20

Playing with SimpleFirewall I wanted to access a file in Downloads folder.

Whose Download folder? Keep in mind that a sysex runs as root, so there could be many different users to choose from.

I found the explanation in

I’m sorry to report that this is misleading. That text is accurate for iOS, where there’s a strict separation between filter data and control providers, but that separation doesn’t exist on macOS.

I suspect that you’re actually hitting the user data protection control that we added in 10.15.

I understand the reasoning but, I wanted to confirm if I'm left with no options at all to access any files outside the bundle. Not even in the Group container to exchange data with another process with the same goup ID?

Are your referring to a

gid_t

or to a shared app group? The problem with the latter is, again, that you’re running as root and a shared app group’s container is per user.

How about connecting a UNIX domain socket, it is a FD, same resrictions?

UNIX domain sockets represent additional complications, as I recently described in this thread.

XPC to another process (Not the Host App) with the same group ID?

Do you plan to distribute in the Mac App Store? Or independently via Developer ID?

Does or will the ES Sysex have restrictive sandboxing as well ?

ES sysexes are not sandboxed.

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

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

0

Answer 2

Jon Gabilondo OP

Jun ’20

I confirm that the sandboxed NE sysex does create the Group Container in /private/var/root/Library/Group Containers

therefore is different that the container-App which is in /Users/me.user/Library/Group\ Containers

I can access files in /private/var/root/Library/Group Containers

I have been able to connect to a UNIX socket in /private/var/root/Library/Group Containers

Does this mean that for a NE Sysex on Mac:

DOES NOT run in a very restrictive sandbox. The sandbox DOESN NOT prevents the Filter Data Provider extension from moving network content outside of its address space by blocking all network access, IPC, and disk write operations. (?)

Thanks!

0

Answer 3

DTS Engineer OP

Apple

Jun ’20

DOES NOT run in a very restrictive sandbox.

Correct. The quote from the docs that you referenced in your original post was written prior to the introduction of filter providers on the Mac, and thus it only applies to iOS. I’d appreciate you filing a bug to get it updated.

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

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

0

Answer 4

Jon Gabilondo OP

Jun ’20

Filed FB7729428

Thanks

0