CODEWITHSUNDEEP
iosiphonesocketstcpsocketgcdwebserver
HungryTux
HungryTux

Reputation: 355

iOS app sandbox for accepting connections on TCP sockets

I'm making use of the library GCDWebServer(https://github.com/swisspol/GCDWebServer) in a project of mine, that requires me to accept connections originating only from my application's process, for security reasons. I was hoping this is something that the iOS app sandbox would provide out of the box, but that doesn't appear to be the case. The sandbox appears to be enforced for UNIX domain sockets(AF_UNIX), by means of file-system permissions. But for TCP/IP sockets(AF_INET), used by GCDWebServer, there appears to be no sandboxing in place.

I was able to write two sample applications - a client and a server(signed with different developer certificates) and could have them communicate with each other, without any issues.

I was wondering if there was some way of enforcing the same on iOS, essentially spin up a HTTP server on a TCP socket but only accept connections from the same process. I can't make use of UNIX domain sockets, because the client which is going to request the content from the HTTP server is an AVPlayer and it wouldn't know how to connect to my application's UNIX domain socket.

Upvotes: 1

Views: 989

Answers (2)

Pol
Pol

Reputation: 4008

There are many ways you could do that: you can inspect the incoming request in GCDWebServer and decide if you want to respond to it or return an error.

You could add a secret header other apps wouldn't know about, sign the entire request with a secret key, etc...

Upvotes: 1

dgatwood
dgatwood

Reputation: 10417

I'm about 99% certain that what you're asking for is impossible. I don't even think it is possible in OS X without writing a network kernel extension (and even then, it would be challenging).

By the time a network request reaches another process, it has passed through the networking stack and has lost any notion of what process originated the connection (unless this has improved fairly recently).

Realistically, the closest you can get is binding to a random port on the localhost interface and tearing it down as soon as your app gets put into the background.

Pedantically, if you managed to somehow convince Apple that you planned to build a VPN, it is theoretically possible to abuse the VPN API in such a way that would let you provide a private network that worked only within your app. It would not, however, ever be allowed in the app store.

But why would you ever want to do this? AVPlayer is more than capable of playing from a file URL.

Upvotes: 1

Related Questions