Traceroute from Sandbox

I’m trying to add traceroute to an app that has some network tools on it but if I try to run traceroute from the shell when the app is sandboxed I get the following message:

If I include a copy of traceroute as a resource file and attempt to run it from within the sandbox I get the following error, even if I use the -P argument to change the protocol:

Any ideas on how to get this working from the sandbox?

Are you intending to ship on the App Store? If you are, you may be out of luck. If not, just abandon the App Sandbox.

I recently had a similar issue with an app on the App Store; Apple’s response was remove that function or ship elsewhere. I was quite a bit shocked that they had taken this attitude.

Oh sorry; about including traceroute in your bundle:
#1 Make sure that you have the networking client options enabled in App Wrapper.
#2 The traceroute executable will need to be code signed, place it in the “MacOS” folder (next to your main application) and App Wrapper will code sign it correctly for you.
#3 You’ll need to use NSTask to launch the executable as the Xojo Shell class cannot launch Sandboxed terminal apps.

Thanks for the information. I’ll set the app up that way and post an update later.

Apple is not alone in this car: I also saw some other software companies that removes a feature vs debugging it / provide a full functional version.

Strange attitude, but this may be the new one for this millenium (as many I already saw).

Terratec Home Theater (DVT Software): the number you have to type in your remote is different from the TV channel. Their new owner (like the old one) does not think that this is a bug !
(when I press the 3 digit on my remote, I do not get France Television 3, but a German TV… Niiiiice).

[quote=288478:@Emile Schwarz]Terratec Home Theater (DVT Software): the number you have to type in your remote is different from the TV channel. Their new owner (like the old one) does not think that this is a bug !
(when I press the 3 digit on my remote, I do not get France Television 3, but a German TV… Niiiiice).[/quote]
We live in a world where bugs are so common, that software vendors simply don’t feel they have to try so hard any more.

[quote=288442:@Sam Rowlands]Oh sorry; about including traceroute in your bundle:
#1 Make sure that you have the networking client options enabled in App Wrapper.
#2 The traceroute executable will need to be code signed, place it in the “MacOS” folder (next to your main application) and App Wrapper will code sign it correctly for you.
#3 You’ll need to use NSTask to launch the executable as the Xojo Shell class cannot launch Sandboxed terminal apps.[/quote]
I’ve tried setting up NSTask from the macoslib files but I keep getting a ton of error messages. Do you have an example project for how you’re using NSTask?

I downloaded the Cocoa plugins from MBS. I have copies of traceroute, ping and lft in the MacOS folder in the app bundle and NSTaskMBS will launch them but they can’t get network access. This looks like an entitlement problem with the helper apps. The AppWrapper settings appear to be correct and if I check the app it shows the helper apps are codesigned but I’m not sure about the entitlements for the helper apps, or if it is even possible to use shell apps as helper apps.

You should not need copies of ping in your bundle. Ping is a standard OS X command. It is in /sbin/ping

That is what I suspected : you do not even need NSTask, since Ping is part of OS X.

I created a test app with this in a button:

[code]Sub Action() Handles Action
s = new shell

s.execute “ping -c 5 fontmenu.com
msgbox s.result

End Sub
[/code]

Then sandboxed it with App Wrapper. In capabilities, make sure to check Server and Client allowed.

Traceroute is another story. It triggers the message :
bash: /usr/sbin/traceroute: Operation not permitted

I suspect you need a temporary entitlement for traceroute, or a special setting in App Wrapper. Maybe Sam knows more. I googled ‘temporary entitlement traceroute’ to no avail.

There are traceroute apps in the MAS, though. So there is a way.

[quote=289275:@Michel Bujardet]That is what I suspected : you do not even need NSTask, since Ping is part of OS X.

I created a test app with this in a button:

[code]Sub Action() Handles Action
s = new shell

s.execute “ping -c 5 fontmenu.com
msgbox s.result

End Sub
[/code]

Then sandboxed it with App Wrapper. In capabilities, make sure to check Server and Client allowed.

Traceroute is another story. It triggers the message :
bash: /usr/sbin/traceroute: Operation not permitted

I suspect you need a temporary entitlement for traceroute, or a special setting in App Wrapper. Maybe Sam knows more. I googled ‘temporary entitlement traceroute’ to no avail.

There are traceroute apps in the MAS, though. So there is a way.[/quote]
Thanks for the comments. I have successfully run ping from the shell but traceroute is another issue, as is lft. I suspect it’s an entitlement issue but I haven’t figured out how to set an entitlement for a terminal app in App Wrapper.

It is indeed an entitlement issue. Now which one…

I use the OWShell script from my Sandbox Kit source code.

#1 In the “Capabilities” pane of App Wrapper, make sure that “Client” is selected in the “Networking” section.
#2 Yes it’s possible to use terminal application as helpers, I do this time.

You may need to check the console, if none of the above works, you may need a “Temporary Entitlement”, I’m thinking probably a MachO allowance of some kind, which sadly means that your application will not be permitted on the App Store.

if traceroute wont run but ping does couldn’t you just do the traceroute with that? Do a single ping with the max hops ( -m 1) and parse out the response with the machine that returned the error, then run it again with -m 2 and do forth until you reach the destination machine address. Each time getting your own error from the various machines that are sending back the error. Thats really all traceroute does :slight_smile:

[code]SandboxViolation: bash(2109) deny forbidden-exec-sugid
Violation: deny forbidden-exec-sugid
Process: bash [2109]
Path: /bin/bash
Load Address: 0x100b62000
Identifier: bash
Version: ??? (???)
Code Type: x86_64 (Native)
Parent Process: trace [2074]
Responsible: /Users/Mitch/Downloads/Builds - trace/Mac OS X (Cocoa Intel)/Wrapped Application/trace.app/Contents/MacOS/trace [2074]
User ID: 501

Date/Time: 2016-09-30 17:43:45.462 GMT+2
OS Version: Mac OS X 10.12.1 (16B2333a)
Report Version: 8

Thread 0 (id: 925154):
0 libsystem_kernel.dylib 0x00007fff8ac6a816 execve + 10
1 bash 0x0000000100b81c20
2 bash 0x0000000100b7371c
3 bash 0x0000000100b6462f
4 bash 0x0000000100b63a17
5 libdyld.dylib 0x00007fff8ab3b255 start + 1
6 bash 0x0000000000000003

Binary Images:
0x100b62000 - 0x100be5fff bash (103) <266dd3a0-ba2d-38f8-8a93-8022f6053cd0> /bin/bash
0x7fff8ab36000 - 0x7fff8ab3bff3 libdyld.dylib (421.2) <312f7f4e-c9ef-33e6-9256-1306be718a9b> /usr/lib/system/libdyld.dylib
0x7fff8ac50000 - 0x7fff8ac72ff7 libsystem_kernel.dylib (3789.20.49) /usr/lib/system/libsystem_kernel.dylib[/code]

Found this on SO:

Invoking /usr/sbin/traceroute is prohibited from a sandboxed app because it’s a setuid binary. This is a really reasonable thing because otherwise the sandboxed app would be able to invoke a process as root and control the inputs it’s given, which is a good way to gain access to the rest of the system if there’s any bugs.

Invoking the traceroute copied into your app results in it inheriting the app’s sandbox. This prevents traceroute from creating its ICMP sockets because network-outbound entitlement only allows IPv4, IPv6, and Unix domain sockets to be used.

[quote=289323:@Michel Bujardet]SandboxViolation: bash(2109) deny forbidden-exec-sugid
Violation: deny forbidden-exec-sugid[/quote]

Then this is a flat out nope, can’t be done. If you want to release your application, you’ll need to look elsewhere than the App Store.

On a pure technical curiosity level, I wonder how the guys who have trace apps in both the MAS and iOS App Store have figured that out. They probably rewrote they own traceroute from scratch.

They must have written their own since I had the same issues using nslookup. I was denied when I tried to use the Server Entitlement and of course it won’t work without it. I ended up using a DNS A Record API service and continued using my client network entitlement.