17 thoughts on “ macOS: How to run your Applications in a Mac OS X sandbox to enhance security ” Pingback: Maximum security and privacy using Mac OS sandbox and Tor browser bundle Paolo Fabio Zaino's Blog. Pingback: Doing app builds in a sandbox. Best Wordpress Themes - Reviews. With a growing community of over 1 million Sandboxx users, we are continuing to build more products to help. Get access to base specific training updates from within the app as your recruit progresses through basic training. Refer friends and family to earn free Letters and ensure your service member can receive even more mail. The app is sandboxed. This means the application has been code signed with a set of entitlements. These entitlements are being enforced by Mac OS X. Apple's developer documentation on sandboxing provides more detail.
Hi there! It’s GeoSn0w. The macOS Sandbox has always been a mysterious thing that I liked to poke at with various tools and with the knowledge I have gathered from reference books such as Jonathan Levin’s *OS Internals, and Apple’s own not-so-detailed documentation. Of course, it’s nothing new that Apple’s documentation on their own security mechanisms isn’t the best. The Sandbox has a very long history and it’s been with us, macOS users for quite a long time, only to spin off to iOS and the rest of the *OSes and to become more powerful over time. Apple’s been doing their darn best to harden the Sandbox as well as many other security mechanisms in their operating systems, so let’s grab a cup of coffee and dive a bit into the marvel that is the macOS Sandbox.
A bit of historical value
The Sandbox is definitely not new. It’s been first introduced in OS X 10.5 “Leopard”, many, many moons ago, and it was called “SeatBelt”. The idea was simple, just like you buckle your seatbelt to be safe on a car journey, the developer should voluntarily enforce the sandbox upon their applications to restrict their access to the system. As you can probably imagine, not many developers did this, and since the initial concept of the “SeatBelt” was voluntary confinement, Apple couldn’t do much. Paired with the
MandatoryAccessControl (MAC) Framework
, the idea of Sandbox was definitely not bad, but nowhere near successful. The MACF framework is pretty much the foundation on top of which the entire security model of the Apple devices is built.Enter OS X 10.7. With Apple having learned their lesson, SandBox evolves now to no longer depend on the developer to enforce it upon their apps, it is enforced by default. Thing is, Apple enforces the SandBox, even as of today on macOS Mojave, based on an entitlement the applications own, which is
com.apple.security.app-sandbox
. If the application has this entitlement, it will be placed in a container regardless of the wish of the developer. To be frank, developer’s opinion is kinda moot anyway, because applications uploaded into the macOS App Store are signed by Apple and during the signing process, Apple graciously slaps the Sandbox entitlement on the application thus forcing the containerization of any App Store application.An important aspect to keep in mind is that compared to iOS’ Sandbox, macOS has it easier. See, on iOS, there is no way for you, a third party app developer to ever escape your Sandbox unless you use a Sandbox escape technique, most of the times powered by a Kernel exploit or a Sandbox escape exploit. All 3rd-party applications, regardless of where they’ve been installed / side-loaded from, are placed on iOS in
/var/mobile/Containers
and /var/Containers
. These paths have changed a lot beginning with iOS 8 when new folders were created and things were moved around to separate App resources, static from runtime data, so on older iOS, you may find the apps installed in /var/mobile/Applications
or even /var/mobile/Containers/Bundle/
. It doesn’t matter. Anything in /var/
is destined to be Sandboxed and there is no way around it because you cannot just install your app elsewhere, unless you Jailbreak the device, of course. On macOS, only App Store apps are guaranteed to be sandboxed. If you get an application in a DMG image from a developer website (which is extremely common), it is very likely not sandboxed.But what exactly is the Sandbox doing anyways?
The Sandbox’ sole purpose is to restrict applications from accessing various resources of the system. This can be either syscalls, files or whatever. It’s pretty much put in place to do damage control. See, on iOS for example, if you’re gullible enough, I can trick you into installing a malicious application, but it would be pointless because unless I go out of my way to use a Kernel or Sandbox escape exploit (which are usually not available for the latest iOS version), then my application cannot do much harm to your device. If I want to be a complete dick and remove some important files from your phone to make it never boot again, I cannot. Stock iOS enforces the Sandbox amongst other protections against unauthorized access, so my application will have access to nothing but its own container in which it cannot do much damage. The app may still be able to collect some data or do some nasty stuff, but nowhere near the imminent death it could have caused to the system had it had unfettered access. The same thing applies to macOS App Store apps, but not for apps that come in DMG format which are likely not sandboxed.
The Sandbox is actually a very good idea, that’s probably why it stuck with Apple to the present day. Imagine Windows. I can trick you fairly easy to open a program you downloaded from a shady source and that program will graciously delete the
System32
folder or other important files. Why? Because there is no Sandbox in place on Windows. Yes, some resources need the user to confirm they want to open a program in “Administrator mode”, thus elevating the privileges, but it has become second nature to many people to just press “Run”, so it won’t protect much.Apple puts it simply: Sandbox is an access control technology enforced at kernel level (where you, the user, or any compromised app from whatever source wouldn’t normally have control). The Sandbox pretty much ensures that it hocks (intercepts) all operations done by the sandboxed application and forbids access to resources the app is not given access to. You can imagine throwing your app in a jail cell and watching its every step.
On macOS, the Sandbox itself is not a single file or a single process, it is split into multiple components that work together to create the Sandbox. At first, we have the
userland daemon
located in /usr/libexec/sandboxd
, there is the com.apple.security.sandbox
which is a kext (Kernel Extension)
, and there’s also the AppSandbox
private framework which relies on AppContainer.Framework
. As you can see, multiple components work together to implement what we call the App Sandbox
.You can see the kext being active on macOS by running the
kextstat | grep 'sand'
command in Terminal.The Sandbox is one of the multiple
MACF Policy modules
. The CodeSign
enforced by AMFI (Apple Mobile File Integrity)
is another module.Experiment: Determining whether an app on macOS is sandboxed or not based on its entitlements
Human japanese mac torrent. As I mentioned earlier, a telltale sign that the app is sandboxed, is the presence of
com.apple.security.app-sandbox
entitlement in the application binary. We can check the entitlements on macOS using multiple tools, but my favorite is jtool
by Jonathan Levin. By running the command ./jtool --ent /Applications/AppName.app
in Terminal, we can see the full list of entitlements that the application possesses. Let’s try it with iHex, an app I got from the macOS App Store, and then with OpenBoardView - an app downloaded in DMG format.Running the command in Terminal yields the following result for iHex:
Alright, so, a few things demand an explanation here. At first, as you can see, the entitlement is present and the key is set to
true
. This application will be Sandboxed. Now, as you could see, these entitlements are listed in a format akin to XML. That is because they’re actually in a .PLIST or Property List
file which is nothing but a glorified XML. PLISTs can, however, come in binary format, but one can easily convert them in the human-readable format by using the command plutil -convert xml1 -o
.Using
Jtool
, one can easily replace the entitlements of the application but that requires fake-signing the app. All in all, this is a method to unsandbox a macOS application. This cannot be easily done on iOS because the sandboxing there is based on the location where the app is installed and not solely on the possession of an entitlement.Let’s now take a look at OpenBoardView, an app that wasn’t downloaded from the App Store.
As you can see, the application has no entitlements whatsoever. It will not be sandboxed and this means that it can access way more sources than any App Store application. We can inject the sandbox entitlement into it with
jtool
, but the point is, yes, non-App Store apps are, indeed, more dangerous.Remember, the
com.apple.security.app-sandbox
entitlement was not added by the developer of the iHEX application, it was added automatically by Apple in the process of signing when the application got published in the App Store and there is nothing the developer could do to remove the entitlement, other than distributing their app via other means. Normally the entitlements tell what your application CAN do. In the case of this entitlement, it pretty much limits the application heavily from accessing system resources or user data.Another way of checking whether the application is sandboxed or not is to run the command
asctl sandbox check --pid XYZ
where XYZ is the PID (Process ID)
of the application you’re interested in. You can get the PID
of a running process from the Activity Monitor
application on macOS. Here’s the output of the asctl
command.How is the Sandbox enforced?
Okay, we established what the Sandbox is, how you know you are sandboxed and why you are sandboxed in the first place, but what exactly happens when a sandboxed application runs?
Enter containers. A container is pretty much just a folder placed on
$HOME/Library/Containers/
. This folder is created for any sandboxed application regardless of the place the actual binary is installed on. The folder follow a simple structure, but most importantly, it contains a Container.Plist
file which contains information about the application whose Container this is (identified by its CFBundleIdentifier
), the SandboxProfileData
, the SandboxProfileDataValidationInfo
and the Version
of the Sandbox.Let’s find iHEX’ Container.We can easily do that by changing directory (cd) to the path mentioned above, and then running
ls -lF com.hewbo.hexeditor
. Where com.hewbo.hexeditor
is the CFBundleIndentifier
of the iHex app (you can find it in the Info.Plist
inside the .app folder).Okay, so you can see that the container of the app contains a
Data
folder as well as the aforementioned Container.Plist file. The Data folder is very interesting. If you change directory (cd) into it you can see that it simulates the user’s Home directory. Of course, all of those are tightly controlled symlinks. The control is being enforced by the Container.plist which contains the SandboxProfileDataValidationRedirectablePathsKey
that dictates which symlinks are approved.Sandboxed from moment one
When you start an application, internally, the Kernel will get to call the function
mac_execve
, which can be seen in the XNU source code. The __mac_execve
will pretty much load the binary but it will also check the MAC label
to see whether Sandbox should be enforced. At this point, the system is aware that you are going to be Sandboxed but you’re not just yet.When the process starts, quite eraly in its lifetime it will load
libSystem.B
because all the APIs rely on it. At some point during the execution, libSystem.B.initializer
will fall to _libsecinit_setup_secinitd_client
which will then fall to xpc_copy_entitlements_for_pid
to grab the Entitlements from the application binary, and then it will send the entitlements as well as whether the application is supposed to be sandboxed via an XPC message to secinitd
daemon located in /usr/libexec/secinitd
. This message transfer happens at xpc_pipe_route
level. The same function will handle the message receive from the secinitd
daemon which will parse the XPC message received from the process.The
secinitd
dameon will acknowledge the fact that sandboxing should be enforced if the entitlement is present, then it will call upon the AppSandbox.Framework
to create the sandbox profile
. After the profile is created secinitd
will return an XPC message
containing the CONTAINER_ID_KEY, CONTAINER_ROOT_PATH_KEY, SANDBOX_PROFILE_DATA_KEY
, amongst other data. This information will be parsed by _libsecinit_setup_app_sandbox
which then falls into __sandbox_ms
thus creating the sandbox of the application and containerizing it at runtime. How to delete facetime app on macbook air.Since this is a pretty confusing explanation, thanks to a diagram made by Jonathan Levin (Figure 8-4) in *OS Internals Volume III, I managed to create my own version of the diagram which is a bit more simplified but should suffice. Huge thanks to Jonathan for his research, it is him who put together the research material I used to understand how the Sandbox works.
Experiment: Tracing the App Sandbox as it is being created at runtime
So, now that we have an idea of how the Sandbox works, let’s see it in action. Using LLDB we can debug a sandboxed application and see exactly what is going on, down to the XPC messages being passed over from the process to
secinitd
daemon. We’re about to dive into Terminal and LLDB, so the following listing may appear very hard to follow. To make it easier on yourself to understand what is going on, it’s best to try to follow the important logic like the messages being passed around and the backtrace to see what function calls we do.At first, we start by opening the Terminal and calling lldb. If you don’t have LLDB installed, install Xcode as it comes with all the debugging tools you need. First, we start by setting a few break points. We’re doing to break at
xpc_pipe_routine
where the XPC messages are sent and received, and at __sandbox_ms
which is the Sandbox MACF syscall.All fine and well, our breakpoints worked and we are now in
libxpc.dylib
and we stopped at the xpc_pipe_routine
. Let’s do a backtrace
to see what is going on. We can do that with the bt
command.Nope, not what we need. This is the
_xpc_uncork_domain
function of libxpc.dylib
. We need the xpc_pipe_create
one. We press c
to continue and backtrace again.Yep! We found what we need, the
xpc_pipe_create
function. Now thanks to Jonathan Levin, I learned that you can use the p (char *) xpc_copy_description($rsi)
to view the message that is being sent through the XPC pipe which is super useful for debugging. We use the RSI
register as the message is the second argument (the first one is the pipe).Unfortunately, not what we need. This is just a handshake message. We continue.
Aargh! There we go! The precious message containing our application’s entitlements and whether it is a candidate for the sandbox. As you can see, the
SECINITD_REGISTRATION_MESSAGE_IS_SANDBOX_CANDIDATE_KEY
is set to bool true
and we do possess the com.apple.security.app-sandbox
entitlement. We’re bound to be sandboxed.Now that we saw exactly what the process has sent to
secinitd
, let’s see if the sandbox is being created. For that we’re using the second breakpoint we’ve set, the one on __sandbox_ms
. Since the breakpoint is already set, we continue (c) until we hit it.And there we go, a call to
_libsecinit_setup_app_sandbox
of libsystem_secinit.dylib
which means that our Sandbox has been created and we’re about to be placed into it as we start. The next few continue commands would finally fall into sandbox_check_common
of libsystem_sandbox.dylib
and then finally into LaunchServices
after which the app is started through AppKit`-[NSApplication init]
.After this, the application interface is rapidly built by the rest of the components and the app starts sandboxed.
Acknowledgements
Thank you a lot for reading through this! I hope you find it useful. In the end, I’d like to thank Jonathan Levin for both his presentation at HITBGSEC 2016 about the Sandbox and for his marvelous *OS Internals Volume III book which is pretty much the main resources I’ve studied to understand the sandbox and to be able to write this article. It’s Jonathan whom you shall thank for the research and the effort put into the uncovering of Apple Sandbox’ inner workings and if you can buy his *OS Internals series, please do - they are absolutely fantastic books with tons of research put into iOS, macOS, watchOS and tvOS.
Bibliography
- 2016 J. LEVIN, *OS Internals Volume III Security & Insecurity, NY, USA, TechnoloGeeks
- 2016 J. LEVIN, The Apple Sandbox: Deeper Into The Quagmire, presentation at HITBGSEC 2016 conference
- Apple Sandbox Design Guide, accessed on December 27 2018
- App Sandbox In Depth, accessed on December 27 2018
- 2016 D. Thiel, iOS Application Security The Definitive Guide for Hackers and Developers, No Starch Press, San Francisco, USA
Contact me
- Twitter: GeoSn0w (@FCE365)
- YouTube: F.C.E. 365 TV- iDevice Central
App Sandbox is an access control technology provided in macOS, enforced at the kernel level. It is designed to contain damage to the system and the user’s data if an app becomes compromised. Apps distributed through the Mac App Store must adopt App Sandbox. Apps signed and distributed outside of the Mac App Store with Developer ID can (and in most cases should) use App Sandbox as well.
At a Glance
Complex systems will always have vulnerabilities, and software complexity only increases over time. No matter how carefully you adopt secure coding practices and guard against bugs, attackers only need to get through your defenses once to succeed. While App Sandbox doesn’t prevent attacks against your app, it does minimize the harm a successful one can cause.
A non-sandboxed app has the full rights of the user who is running that app, and can access any resources that the user can access. If that app or any framework it is linked against contain security holes, an attacker can potentially exploit those holes to take control of that app, and in doing so, the attacker gains the ability to do anything that the user can do.
Designed to mitigate this problem, the App Sandbox strategy is twofold:
- App Sandbox enables you to describe how your app interacts with the system. The system then grants your app the access it needs to get its job done, and no more.
- App Sandbox allows the user to transparently grant your app additional access by way of Open and Save dialogs, drag and drop, and other familiar user interactions.
App Sandbox is not a silver bullet. Apps can still be compromised, and a compromised app can still do damage. But the scope of potential damage is severely limited when an app is restricted to the minimum set of privileges it needs to get its job done.
App Sandbox is Based on a Few Straightforward Principles
By limiting access to sensitive resources on a per-app basis, App Sandbox provides a last line of defense against the theft, corruption, or deletion of user data, or the hijacking of system hardware, if an attacker successfully exploits security holes in your app. For example, a sandboxed app must explicitly state its intent to use any of the following resources using entitlements:
- Hardware (Camera, Microphone, USB, Printer)
- Network Connections (Inbound or Outbound)
- App Data (Calendar, Location, Contacts)
- User Files (Downloads, Pictures, Music, Movies, User Selected Files)
After install app stays on mac desktop. Access to any resource not explicitly requested in the project definition is rejected by the system at run time. If you are writing a sketch app, for example, and you know your app will never need access to the microphone, you simply don’t ask for access, and the system knows to reject any attempt your (perhaps compromised) app makes to use it.
On the other hand, a sandboxed app has access to the specific resources you request, allows users to expand the sandbox by performing typical actions in the usual way (such as drag and drop), and can automatically perform many additional actions deemed safe, including:
- Invoking Services from the Services menu
- Reading most world readable system files
- Opening files chosen by the user
The elements of App Sandbox are entitlements, container directories, user-determined permissions, privilege separation, and kernel enforcement. Working together, these prevent an app from accessing more of the system than is necessary to get its job done.
Relevant chapters:App Sandbox Quick Start, App Sandbox in Depth
Design Your Apps with App Sandbox in Mind
After you understand the basics, look at your app in light of this security technology. First, determine if your app is suitable for sandboxing. (Most apps are.) Then resolve any API incompatibilities and determine which entitlements you need. Finally, consider applying privilege separation to maximize the defensive value of App Sandbox.
Xcode Helps You Migrate an Existing App to App Sandbox
Some file system locations that your app uses are different when you adopt App Sandbox. In particular, you gain a container directory to be used for app support files, databases, caches, and other files apart from user documents. Xcode and macOS support migration of files from their legacy locations to your container.
Relevant chapter:Migrating an App to a Sandbox
Preflight Your App Before Distribution
After you have adopted App Sandbox in your app, as a last step each time you distribute it, double check that you are following best practices.
How to Use This Document
To get up and running with App Sandbox, perform the tutorial in App Sandbox Quick Start. Before sandboxing an app you intend to distribute, be sure you understand App Sandbox in Depth. When you’re ready to start sandboxing a new app, or to convert an existing app to adopt App Sandbox, read Designing for App Sandbox. If you’re providing a new, sandboxed version of your app to users already running a version that is not sandboxed, read Migrating an App to a Sandbox. Finally, before distributing your app, work through the App Sandbox Checklist to verify that you are following best practices for App Sandbox.
Mac Os Sandbox App Windows 10
Prerequisites
Before you read this document, make sure you understand the overall macOS development process by reading Mac App Programming Guide.
See Also
To complement the damage containment provided by App Sandbox, you must provide a first line of defense by adopting secure coding practices throughout your app. To learn how, read Security Overview and Secure Coding Guide.
An important step in adopting App Sandbox is requesting entitlements for your app. For details on all the available entitlements, see Entitlement Key Reference.
Macos Sandbox App
You can enhance the benefits of App Sandbox in a full-featured app by implementing privilege separation. You do this using XPC, a macOS implementation of interprocess communication. To learn the details of using XPC, read Daemons and Services Programming Guide.
![Sandbox Sandbox](/uploads/1/2/6/8/126858936/169434980.jpg)
Copyright © 2016 Apple Inc. All Rights Reserved. Terms of Use | Privacy Policy | Updated: 2016-09-13