Sandbox: how to have protected apps in macOS and iOS? #2
We continue to speak of the mechanism of the sandbox, a unique feature that allows you to run apps in an isolated environment to ensure the safety; we started to discuss the operation in the previous article.
The mechanism sandbox is undoubtedly powerful and very advanced compared to similar mechanisms in other operating systems. However, it is not infallible. The approach of the “black list” that blocks hazardous operations notes is just as effective as the list is restrictive. For example, in November 2011, researchers from Core Labs have shown that the profile no-network macOS Lion limited actual access to the network, but is not limited AppleEvents.
What this means, in a nutshell?
Simply, an app is malicious does not connect to the internet because it blocked by the sandbox, but, he was easily able to activate the AppleScript, and connect to the network through a proxy process, not sandboxato.
The sandbox, and then it was improved again in macOS Mountain Lion, where it was renamed the GateKeeper, who introduced the famous set of extended attributes-related quarantine, responsible for the family box warning ‘This is an application downloaded from the Internet’.
With the advent of the GateKeeper was also introduced a new command to the command line, asctl, which allows the adjustment of a lot more delicate mechanism of the security sandbox. This utility allows you to start applications and to track their activity in the sandbox, building a custom profile based on the requirements of the app, how it behaves. It also helps you establish a “container” for a mobile app, in particular those in the Mac Store, these containers are simple folders for the app, stored in the path Library/Containers.
The permissions that are granted to the app, are very similar in terms of the mechanism to those used in Android, which are also the basis for the security of Dalvik. These permissions, rights, are not simply a list of properties.
FreeBSD was the first to introduce a powerful security feature known as Mandatory Access Control (MAC). This function, which implements a security model very end, improves the Unix model (rather crude) limiting access to certain files or resources (such as sockets, IPC, and so on) from specific processes, not only by the permissions. In this way, for example, a certain app may be limited so as not to access the private data of the user, services or even some Web sites.
Think of the concept of MAC as a tag: this technology denies access to any object that does not conform to the label; macOS further extends these security policies.
Behind the scenes, who is committed to keep working in the sandbox environment? Obviously the kernel, xnu! The MAC layer of the BSD (described above) is the mechanism by which work for both the sandbox permissions; the extension to the mainline kernel, responsible of the sandbox is sandbox.kext, is common to both the macOS to iOS. A second extension of the kernel, only for iOS, is AppleMobileFileIntegrity (the glorious, as the famous AMFI) that applies the permissions, and code signing (and is the cause of the unceasing work of the do). In addition, the sandbox also has a dedicated daemon, /usr/libexec/sandboxd, which is run in user mode (user mode) to provide track of the services sandboxati and is started on demand. Even in iOS, there is the AMFI, which even has its own dedicated daemon, /usr/libexec/amfid.
The architecture of the sandbox in macOS is the following:
Also this article is all about. For any questions, curiosity or feedback you can leave a comment below, see you soon!
Link to the original article: the Sandbox: how to have protected apps in macOS and iOS? #2