Is it possible to connect to unix socket from sandboxed applicaiton?

Hi.


I'm trying to connect to docker.sock from my application, but when i enable sandbox entitlement i get following error in console:


deny(1) network-outbound /Users/mihaildemidoff/Library/Containers/com.docker.docker/Data/docker.sock


My environment:

OSX 10.15.2

Docker client https://github.com/valeriomazzeo/docker-client-swift

Swift 5.1.3


Code snippet to reproduce(docker should be installed):

let dockerClient = DockerClient(unixSocketPath: "/var/run/docker.sock")
let url = URL(string: "http:/v1.24/containers/json?all=1")!
let request = URLRequest(url: url)
let result = try dockerClient.respond(to: request)

I tried many solutions, but failed with each. So, is it possible to connect to unix socket(especially to docker socket) from sandboxed application?


Thanks

Accepted Reply

There is no "of course" here in the developer forums. There is no way to tell how much someone knows about the platforms or programming in general.


You might have some difficulty getting such an app into the App Store. I know there are apps in the store that depend on other apps, but I don't know how that works in terms of app review. I can give you technical suggestions on how to live within the sandbox, but be forewarned, you might have other problems later. I've done some really funky things in the Mac App Store and I wouldn't recommend that anyone else attempt things like this in the Mac App Store. It's good for stand-alone apps.


Wither the Docker socket is a symbolic link in /var or a link in some other app's container doesn't matter. Your sandboxed app is going to have difficulty finding and accessing such an object. I asked about the possibility of a sandboxed Docker because the source of that link looks like it is inside the container of another sandboxed app. It's just a curious path for a non-sandboxed app. But ultimately it doesn't matter, it is in a user's home directory where your sandboxed app cannot access.


I'm not sure about trying to use a symbolic link in a common area like /var to point to an otherwise inaccessible file. I don't know if that is sufficient to punch a hole in the sandbox. Apple uses links inside the sandbox itself, but this link exists outside of the sandbox. Even if it works, it is risky. It is something that could easily break with a minor update. Plus, this could cause various app review issues. I strongly suggest a more reliable method. After all, it isn't working for you in development either, is it?


A simple solution is to just ask the user to navigate to and select the unix socket. Then you have a security-scoped bookmark that you can save for later use. This is the Gold Standard solution. It will always work and is the least likely to cause app review problems.


Do you have to use a unix socket for this? Would a TCP socket work? A unix socket doesn't make much sense anyway. I can see a Docker UI app being useful to connect to remove Docker instances. A unix socket would only work on the local machine.

Replies

In the Docker instance started from your app (and thus running inside your sandbox)? Or are you trying to connect to a system Docker instance from within your sandbox?

Share and Enjoy

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

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

ps DTS is closed 21 Dec through 1 Jan.

According to your error message, you are trying to attach to a socket at "/Users/mihaildemidoff/Library/Containers/com.docker.docker/Data/docker.sock". But according to your code, you are trying to attach at "/var/run/docker.sock". Neither one is going to work.


First of all, do you have the network client entitlement? Your error message references "network-outbound" so I assume it needs that, even for UNIX sockets. Next, you'll have to find out where Docker is creating its socket. From your error message, that looks like a sandboxed version of Docker. That seems strange. I though Docker needed root. But whatever, you have to pick a path that both apps can access. You may need to use a security scoped bookmark.


Why are you even using the sandbox for this? The Docker client doesn't seem like it was designed for that environment.

I'm trying to connect to system docker from my sandbox.

"/var/run/docker.sock" is just a link to socket in user library:

➜  ~ ls -al /var/run/docker.sock
lrwxr-xr-x  1 root  daemon  75 Dec 31 04:23 /var/run/docker.sock -> /Users/mihaildemidoff/Library/Containers/com.docker.docker/Data/docker.sock


Of course, network client entitlement is enabled.

As i can see from codesign command docker application is not sandboxed

codesign -d --entitlements :- /Applications/Docker.app
Executable=/Applications/Docker.app/Contents/MacOS/Docker
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>com.apple.application-identifier</key>
<string>9BNSXJN65R.com.docker.docker</string>
<key>com.apple.developer.team-identifier</key>
<string>9BNSXJN65R</string>
<key>com.apple.security.app-sandbox</key>
<false/>
<key>com.apple.security.application-groups</key>
<array>
<string>group.com.docker</string>
</array>
<key>com.apple.security.files.user-selected.read-write</key>
<true/>
<key>com.apple.security.get-task-allow</key>
<true/>
<key>keychain-access-groups</key>
<array>
<string>9BNSXJN65R.com.docker.docker</string>
</array>
</dict>

Why i need sandbox? I want to distribute my application through appstore,

There is no "of course" here in the developer forums. There is no way to tell how much someone knows about the platforms or programming in general.


You might have some difficulty getting such an app into the App Store. I know there are apps in the store that depend on other apps, but I don't know how that works in terms of app review. I can give you technical suggestions on how to live within the sandbox, but be forewarned, you might have other problems later. I've done some really funky things in the Mac App Store and I wouldn't recommend that anyone else attempt things like this in the Mac App Store. It's good for stand-alone apps.


Wither the Docker socket is a symbolic link in /var or a link in some other app's container doesn't matter. Your sandboxed app is going to have difficulty finding and accessing such an object. I asked about the possibility of a sandboxed Docker because the source of that link looks like it is inside the container of another sandboxed app. It's just a curious path for a non-sandboxed app. But ultimately it doesn't matter, it is in a user's home directory where your sandboxed app cannot access.


I'm not sure about trying to use a symbolic link in a common area like /var to point to an otherwise inaccessible file. I don't know if that is sufficient to punch a hole in the sandbox. Apple uses links inside the sandbox itself, but this link exists outside of the sandbox. Even if it works, it is risky. It is something that could easily break with a minor update. Plus, this could cause various app review issues. I strongly suggest a more reliable method. After all, it isn't working for you in development either, is it?


A simple solution is to just ask the user to navigate to and select the unix socket. Then you have a security-scoped bookmark that you can save for later use. This is the Gold Standard solution. It will always work and is the least likely to cause app review problems.


Do you have to use a unix socket for this? Would a TCP socket work? A unix socket doesn't make much sense anyway. I can see a Docker UI app being useful to connect to remove Docker instances. A unix socket would only work on the local machine.

Thank you for detailed answer.

After reading your answer i understood that security-scoped bookmark solution will be the best in this case. But this solution wiil be a little unfriendly to users. By the way, its better than nothing.

Acoording to your advice to use tcp socket, i agree that it could be a more suitable solution in sandboxed application but unfortunately docker engine daemon provides only unix socket by default. All other possible options shoud be enabled by user.

You might also want to give some thought to how you are going to get this through app review. As I said before, I don't know how anyone gets something in the Mac App Store that depends on some other app or is a developer tool like this. The people doing app review are not programmers. They are not able to install or configure Docker and I sincerely doubt that they would even be allowed to attempt it.


You may need to build additional functionality in your app just for app review. And as a side effect, it might be useful otherwise. I don't know what your app does, but it sounds like a Docker UI, which is a useful thing. It might be very useful to people who have configured Docker to listen to network requests. What you can do is setup your own Docker environment on AWS as a demo. Give App Review the public-facing AWS URL along with some instructions on how to configure and run a "Hello world" server. This way, they could verify that your app does indeed do what it says. To use this in the real world, you will have to support authenticated connections, so that will be more work. App review might never even check this. But I think it would be a good idea to provide a way to review the app's functionality, without installing any local software, should they choose to do so.


You might also want to give some consideration to why you are putting this in the Mac App Store. It is not going to be a consumer app. You aren't going to make any money on it. There is already a Mac Docker UI in Kitmatic/Docker Toolbox. Before you put too much effort into this, consider the potential reward on your investments of money and time. I'm not saying "don't do it" because I don't know any of the details. But give some thought to this. For example, using a security scoped bookmark will probably work but it requires a locally running version of Docker. Setting up your own Docker server on AWS is a lot of work, but it could also potentially enable an iOS version of your app. That is 10 times the potential market of the Mac, if not more. And even if it isn't profitable in terms of App Store, your app might be the only one that does that. That could lead to other opportunities.