Recent

Author Topic: Sandboxing  (Read 10867 times)

jwdietrich

  • Hero Member
  • *****
  • Posts: 1032
    • formatio reticularis
Sandboxing
« on: February 20, 2012, 01:02:55 pm »
Are there any plans (or even experiences) to support sandboxing on Mac OS X? As of March 1, 2012 all apps submitted to the Mac App Store must implement sandboxing.
function GetRandomNumber: integer; // xkcd.com
begin
  GetRandomNumber := 4; // chosen by fair dice roll. Guaranteed to be random.
end;

http://www.formatio-reticularis.de

Lazarus 2.0.2 | FPC 3.0.4 | PPC, Intel, ARM | macOS, Windows, Linux

Jonas Maebe

  • Hero Member
  • *****
  • Posts: 659
Re: Sandboxing
« Reply #1 on: February 22, 2012, 01:34:27 pm »
Are there any plans (or even experiences) to support sandboxing on Mac OS X? As of March 1, 2012 all apps submitted to the Mac App Store must implement sandboxing.
What kind of support do you mean? Sandboxing means that your application has to include an entitlements plist that indicates what kind of OS functionalities it wants to use (write anywhere on disk, use network communication etc). This is at least unrelated to the compiler. I guess you could add some kind of GUI editor to Lazarus to add the requested entitlements (so that you don't have to use the Property List Editor), but other than that?

ath0

  • Newbie
  • Posts: 2
Re: Sandboxing
« Reply #2 on: June 18, 2012, 12:04:28 pm »
Multi-threaded applications (i.e. any program that tries to create a TThread object) will not work in a sandbox, crashing with "Semaphore init failed" on the Create method of the thread. Any suggestions?
« Last Edit: June 18, 2012, 12:11:43 pm by ath0 »

Jonas Maebe

  • Hero Member
  • *****
  • Posts: 659
Re: Sandboxing
« Reply #3 on: June 19, 2012, 05:35:15 pm »
Multi-threaded applications (i.e. any program that tries to create a TThread object) will not work in a sandbox, crashing with "Semaphore init failed" on the Create method of the thread. Any suggestions?
Mac OS X does not support creating unnamed semaphores, so we create a named semaphore instead. This name has to start with a "/" and can be maximally 31 characters long (although on some systems it's limited to 14 characters). Mac OS X probably interprets this name as a path, because in some ways it behaves like one.

As a result, you may have to add the com.apple.security.temporary-exception.files.absolute-path.read-write entitlement to your application. You may also want to file a bug report with Apple asking them to add a more fine-grained entitlement that only allows the use of named semaphores, rather than having to open up the entire file system for read/write access.

havezet

  • New Member
  • *
  • Posts: 26
Re: Sandboxing
« Reply #4 on: June 24, 2012, 11:19:54 am »
I'm running into the same issues with sandboxing; the threads raise a Semaphore exception. I have added com.apple.security.temporary-exception.files.absolute-path.read-write with an array element for the root to no avail. Any other suggestion?

Another issues that I have is that I can't get the TOpenDialog to run within a sandbox. I found that Powerbox is used and that it should work when NSOpenPanel is used. Not sure if Lazarus does through.

Do you have a suggestion what entitlement I should add for that?

Jonas Maebe

  • Hero Member
  • *****
  • Posts: 659
Re: Sandboxing
« Reply #5 on: June 24, 2012, 11:34:38 am »
I'm running into the same issues with sandboxing; the threads raise a Semaphore exception. I have added com.apple.security.temporary-exception.files.absolute-path.read-write with an array element for the root to no avail. Any other suggestion?
According to http://reverse.put.as/wp-content/uploads/2011/09/Apple-Sandbox-Guide-v1.0.pdf , System V semaphores indeed require their own entitlement. That document only lists the names of the entitlements as they are supported by sandbox_exec/sandbox_init though. I don't whether the entitlements plist allows you to specify a setting that maps to this entitlement. I don't see any relevant one listed at https://developer.apple.com/library/ios/#documentation/Miscellaneous/Reference/EntitlementKeyReference/AppSandboxTemporaryExceptionEntitlements/AppSandboxTemporaryExceptionEntitlements.html

You should probably ask this on an Apple forum or mailing list.

Quote
Another issues that I have is that I can't get the TOpenDialog to run within a sandbox. I found that Powerbox is used and that it should work when NSOpenPanel is used. Not sure if Lazarus does through.

Do you have a suggestion what entitlement I should add for that?
I know next to nothing about GUI programming. I'd try experimenting with the file system entitlements.

havezet

  • New Member
  • *
  • Posts: 26
Re: Sandboxing
« Reply #6 on: June 24, 2012, 05:15:24 pm »
Thanks Jonas. I've logged a support question at Apple.

Btw; this is the error I get for the semaphore init:

Code: [Select]
deny ipc-posix-sem /FPC26886T2888204992
I guess this is the naming you referred to. We'll have to wait if, and how, Apple replies.

Slightly off topic; I personally have a feeling that it could be related to the naming of the semaphore. It's seems logical to expect that a semaphore only operates within the context of the sandbox that it is created in, and that would mean that there has to be a discriminator somewhere for the OS to recognize which semaphore belongs to which process. What better than use the naming for that.

Hert

ath0

  • Newbie
  • Posts: 2
Re: Sandboxing
« Reply #7 on: June 26, 2012, 11:31:19 am »
Mac OS X does not support creating unnamed semaphores, so we create a named semaphore instead. This name has to start with a "/" and can be maximally 31 characters long (although on some systems it's limited to 14 characters). Mac OS X probably interprets this name as a path, because in some ways it behaves like one.

As a result, you may have to add the com.apple.security.temporary-exception.files.absolute-path.read-write entitlement to your application. You may also want to file a bug report with Apple asking them to add a more fine-grained entitlement that only allows the use of named semaphores, rather than having to open up the entire file system for read/write access.

Thanks for the info. It seems like OS X won't allow semaphores at all in a sandbox, so I ended up disabling semaphores in the cthreads unit and recompiled FPC. As far as I can tell, the thread manager now uses file descriptors instead. No more problems with sandboxing. Do you think this might have other side effects?

According to http://reverse.put.as/wp-content/uploads/2011/09/Apple-Sandbox-Guide-v1.0.pdf , System V semaphores indeed require their own entitlement. That document only lists the names of the entitlements as they are supported by sandbox_exec/sandbox_init though. I don't whether the entitlements plist allows you to specify a setting that maps to this entitlement. I don't see any relevant one listed at https://developer.apple.com/library/ios/#documentation/Miscellaneous/Reference/EntitlementKeyReference/AppSandboxTemporaryExceptionEntitlements/AppSandboxTemporaryExceptionEntitlements.html

I don't think the info in the PDF applies to the published way of sandboxing in OS X. It seems to be explaining the internals of sandboxing rather than how we as app developers can use it.

Another issues that I have is that I can't get the TOpenDialog to run within a sandbox. I found that Powerbox is used and that it should work when NSOpenPanel is used. Not sure if Lazarus does through.

Do you have a suggestion what entitlement I should add for that?

com.apple.security.files.user-selected.read-only or com.apple.security.files.user-selected.read-write

Jonas Maebe

  • Hero Member
  • *****
  • Posts: 659
Re: Sandboxing
« Reply #8 on: June 26, 2012, 06:41:47 pm »
Mac OS X does not support creating unnamed semaphores, so we create a named semaphore instead. This name has to start with a "/" and can be maximally 31 characters long (although on some systems it's limited to 14 characters). Mac OS X probably interprets this name as a path, because in some ways it behaves like one.

As a result, you may have to add the com.apple.security.temporary-exception.files.absolute-path.read-write entitlement to your application. You may also want to file a bug report with Apple asking them to add a more fine-grained entitlement that only allows the use of named semaphores, rather than having to open up the entire file system for read/write access.

Thanks for the info. It seems like OS X won't allow semaphores at all in a sandbox,
That's incorrect, it's a permission that can be given to a sandbox (as the pdf I linked below described). The question is only whether it can also be specified (already) via the entitlements.plist file or not.

Quote
so I ended up disabling semaphores in the cthreads unit and recompiled FPC. As far as I can tell, the thread manager now uses file descriptors instead. No more problems with sandboxing. Do you think this might have other side effects?
The only side effect is that your program will require more file handles (2 extra file handles per created-and-not-yet-freed thread), and that this method of synchronisation is slower than semaphores.

Quote
According to http://reverse.put.as/wp-content/uploads/2011/09/Apple-Sandbox-Guide-v1.0.pdf , System V semaphores indeed require their own entitlement. That document only lists the names of the entitlements as they are supported by sandbox_exec/sandbox_init though. I don't whether the entitlements plist allows you to specify a setting that maps to this entitlement. I don't see any relevant one listed at https://developer.apple.com/library/ios/#documentation/Miscellaneous/Reference/EntitlementKeyReference/AppSandboxTemporaryExceptionEntitlements/AppSandboxTemporaryExceptionEntitlements.html

I don't think the info in the PDF applies to the published way of sandboxing in OS X. It seems to be explaining the internals of sandboxing rather than how we as app developers can use it.

It does not describe the internals of sandboxing. It only describes a different interface to exactly the same functionality, and both interfaces can be used by application developers. Whether both can be used by people that want to or are forced to publish via the "AppStore" mess, is a whole other question (and one I can't answer).

havezet

  • New Member
  • *
  • Posts: 26
Re: Sandboxing
« Reply #9 on: June 28, 2012, 11:49:01 am »
so I ended up disabling semaphores in the cthreads unit and recompiled FPC. As far as I can tell, the thread manager now uses file descriptors instead. No more problems with sandboxing. Do you think this might have other side effects?

I did the same for now. At the Developer forums I got this reply from someone who had the exact same issues with using sem_open in a Sandbox:

Quote
I'm having the exact same issue. I haven't found anything about using posix semaphores, but I've switched to using dispatch semaphores and it seems to work so far.

Seems like POSIX semaphores do have their own entitlement but those are currently still undocumented. I'm going to try if I can get those dispatch semaphores into cthreads to replace the POSIX semaphores.


com.apple.security.files.user-selected.read-only or com.apple.security.files.user-selected.read-write

That won't work. The issue is that the CARBON dialog types are not allowed in a Sandbox (not a powerbox). The solution is that NSPanel dialog must be used. In Lazarus/FPC those are defined in the appkit unit. I ended up making my own derived TOpen/TSaveDialog and implemented the NSpanel support in the Execute method.
« Last Edit: June 28, 2012, 11:51:16 am by havezet »

abcSoftware

  • Newbie
  • Posts: 1
Re: Sandboxing
« Reply #10 on: January 24, 2013, 02:45:49 pm »
Thanks for the info. It seems like OS X won't allow semaphores at all in a sandbox, so I ended up disabling semaphores in the cthreads unit and recompiled FPC. As far as I can tell, the thread manager now uses file descriptors instead. No more problems with sandboxing. Do you think this might have other side effects?

can you please tell me, how you managed to include the .entitlements file?
I designed the entitlements file in xcode with en empty project but have no idea, what to do now. The apple-documentation is not helpful either.