Partition functionality, then distrust each partĪn app that is not sandboxed has access to all user-accessible system resources-including the built-in camera and microphone, network sockets, printing, and most of the file system.

Take advantage of access throughout your app

To successfully adopt App Sandbox, use a different mindset than you might be accustomed to, as suggested in Table 2-1. If malicious code gains control of a properly sandboxed app, it is left with access to only the files and resources in the app’s sandbox. The system then grants your app only the access your app needs to get its job done. An attacker needs only to find a single hole in your defenses, or in any of the frameworks and libraries that you link against, to gain control of your app’s interactions with the system.Īpp Sandbox is designed to confront this scenario head on by letting you describe your app’s intended interactions with the system. But despite your best efforts to build an invulnerable barrier-by avoiding buffer overflows and other memory corruptions, preventing exposure of user data, and eliminating other vulnerabilities-your app can be exploited by malicious code. You secure your app against attack from malware by following the practices recommended in Secure Coding Guide. Split your app into smaller parts, each with its own resource privileges, minimizing the damage if any one part becomes compromised. Unambiguously identify your app to the system so another app cannot masquerade as yours. Retain security-scoped bookmarks across launches of your app to any additional files to which the user has specifically granted your app access.Ĭode Signing. Access only the files and directories considered safe for your app. Communicate to macOS the specific system resources your app needs to get its job done, and no more.Ĭontainers. The specific steps you take to adopt App Sandbox are unique to your app, but the access control mechanisms used by App Sandbox to protect user data remain consistent:Įntitlements.

Apple sandbox coding