Mandatory Access Controls (MACs) came out of research in the 1980s on how to improve overall computer security. Published in the famous Rainbow Series by the US DoD and the National Security Agency, they are part of a common understanding of “Trusted Computing,” and especially how to build trusted systems for secure applications.
With this in mind, it’s helpful to know how they work and the different ways they can be leveraged within the corporate IT structure.
A Look at the Basics
MACs are easiest to understand if you consider their opposite, discretionary access controls (DACs). End users are familiar with these: A file is created somewhere, and the owner of the file sets the protection, which is then enforced by the operating system. MACs are different because the user doesn’t have total control over access. Instead, the operating system enforces the controls, and the user can’t change them, even if they’re an administrator.
Here’s a simplified example of how MACs work to enforce authorizations. To implement them, every object — such as a file or disk or a network port — has attached labels that can’t be changed. For instance, when a file with sensitive personal information is created, it might be marked as “PII.” Each process in the operating system also has labels. For example, all of the processes started by a particular user might be marked as “MARKETING” (because the user is in the Marketing group).
When the user tries to touch a file, that’s really a process acting on behalf of the user. In our example, if a Marketing user wanted to read a file they would do so with an application started on their behalf, such as a text editor. That text editor has a set of processes running under it, and they would all get the MARKETING label inherited when the user started the editor.
Now here’s where MACs come in. In addition to all the usual DACs, the operating system consults the MAC policy rules. In this scenario, there might be a rule that says “deny READ by MARKETING to PII.” This way, the MARKETING user can’t read a PII file, even if they own it, have full control, or the protections were changed.
Looking at it from another angle, many processes may be allowed to open internet connections (because of a rule in the MAC policy), but far fewer have access to files marked with the PII label.
Integration Into Android
MACs were put into Linux by the NSA in 2000, and were subsequently merged in to mainline Linux so that admins have had the option of turning on MACs since 2003. The feature was called “Security-Enhanced Linux,” also known as SELinux. In 2012, the NSA began to collaborate with Samsung on integrating MACs from SELinux into Android, and shipped “SE for Android” as part of Android version 4.3 in July 2013.
When SE for Android was first released by Google as part of the mainline Android operating system for implementing containerized applications and application sandboxes, the MACs were not really mandatory. The code was shipped, and a set of access controls were defined. However, if an access control failed, Android just kept on going, allowed the protocol to complete, and logged the violation rather than preventing it.
Mobile Security Is Crucial
White Paper
Find out why Samsung devices are some of the most secure available in this white paper. Download Now
In SELinux terminology, this was called “permissive” mode, because all the software and rules were in place, but actually had no effect. Under pressure from Samsung and the Samsung Knox program, SE for Android became “enforcing” starting with 4.4, meaning that permissions denials are both logged and enforced.
With Android v8, the set of labels has been extended to over 150 different types, including domain, type, class and permission. The result is that somewhere deep in Android is a set of policy rules that say, for example, what the “slideshow” process in Android can do: that is, read files and process graphics.
More importantly, with MACs in place, the “slideshow” process can’t do anything else, which means that if someone figures out a way to take over the slideshow process in your Android smartphone, they can’t affect something going on over on the SD card process that’s busy managing any SD cards in the device, or turn on the microphone to listen in to conversations. This type of defense adds another layer of security and makes it harder for malicious or buggy applications to subvert system security.
Tackling Device Rooting
SE for Android’s first security win was in helping admins prevent rooting of Android phones (typically by malware) — a long-time problem for IT managers trying to protect company data on mobile devices. With enforcing MACs in Android, a compromised process in one part of the smartphone is unable to affect other files and processes. That made rooting Android phones significantly more difficult.
SE for Android comes with a MAC security policy from Google, which is then further refined by each hardware vendor. For example, Samsung’s policy adds in rules that are specific to Samsung devices. One of the strengths of Samsung’s SE for Android policy engine is the automatic updates — rules changing the security policy can be updated between Android software releases. Thus, if an application is found to have insecure behavior, Samsung can quickly update rules and improve operational security.
Although SE for Android provides application isolation far beyond what normal Unix discretionary access controls would support, IT managers should consider it an additional layer beyond other features, such as data separation in Android phones. SE for Android is a broad and fundamental protection mechanism but is not really configurable by admins, which limits their ability to mold policy based on how the device will be used.
The main use of SE for Android is to protect against misbehaving applications, but it does this without having organization-specific context. Thus, some cross-application operations that might be permitted in normal circumstances, such as access to Address Book or Calendar information, might not be appropriate in certain organizations or certain usage scenarios.
Other complementary tools, such as Knox Platform for Enterprise, meet the more specific needs of individual security guidelines, and ensure enterprise adherence. These types of tools tailor the operating system according to organizational policies and context, giving a more precise set of controls to the IT admin.
SE for Android is a feature that provides increased security against internal threats. Most IT managers might not look into all the details — but for those who do, there’s a rich and powerful self-protection system worth exploring.
Gaps in enterprise security can be devastating. Take our mobile security assessment to find out if your company is covered — and how you can stay ahead of the curve.
