By AJ Shipley
In my last blog post, I focused on securing the device at a high level, and in this post, I’d like to dive a bit deeper into the technical aspects of device security; specifically, regarding defense against “run time,” or operational vulnerabilities, that a system is exposed to after it has booted up.
A defense in depth approach requires that we assume that the integrity of the system will be compromised at some point, so we must implement security capabilities that are designed to mitigate such a breach if and when it happens. One of the most devastating outcomes of a cyber security attack is for a malicious user to gain “root” access. The threats that target the largest percentage of vulnerabilities are designed with this specific goal in mind, and in fact, the tagline of the popular Metasploit Framework is “Point, Click, Root.”
If we operate under the assumption that a malicious actor will gain access to the system, we must ask ourselves what is the most effective way to quarantine those bad actors when it happens. Various forms of access control, whether discretionary, non-discretionary, or mandatory access control ensure that if a system becomes compromised, the attacker does not have access to the resources or critical technology contained in the system. Additionally, partitioning technologies such as a hypervisor or a separation kernel, ensure that a compromised operating system is not able to access other operating systems that may be running mission critical applications.
The most prevalent mechanism in place is discretionary access control, which defines permissions for users and groups of users to access various system resources or objects. It is termed discretionary access control because the user has the ability to assign privileges, at his or her discretion, to other users for the resources and objects they have the rights to. Furthermore, there is a notion of a “super user” that typically takes on the form of the root user, which has access to every object in the system. If a perpetrator is ever able to assume the role of the root user they have access to every component of the system, including files like the password shadow file or to secure key stores.
Mandatory access control introduces the concept of subjects and objects. Subjects are active system participants while objects are passive entities such as files or resources. Subjects are assigned different classification levels and the objects are assigned specific labels which designate the classification level that is required to access the object. The system is governed by a security monitor that enforces the access controls to objects by subjects. The notion of a super user or root user is no longer applicable as the “root” user becomes just another user who requires the appropriate clearance to access specific system objects. Mandatory access control alone eliminates a number of the security vulnerabilities of a system and significantly increases the security posture of the operating system, protecting it from a number of privilege escalation attacks. SE Linux and SE Android are real world examples of mandatory access control implemented in the Linux and Android operating system.
Role-based access control is similar to mandatory access control with the difference being that the privileges are assigned to the role that the user takes on instead of the classification being provided to the user itself. An example of this would be an HR user would be given access to HR resources but not given access to payroll resources. Role-based access control is also referred to as non-discretionary access control because the user cannot assign privileges at his or her discretion; the privileges are tied to the role the user assumes instead.
I’ve been on the road a lot lately visiting customers, and the common theme throughout these customer visits is that security is top of mind across industries, regardless of company size or technology being used. The good news is that as a Wind River customer they can be assured that the security is built-in. Our solutions include a combination of pre-deployment development activities (static code analysis, vulnerability analyses, verification test), and post deployment boot and run-time security mechanisms (multi-level security separation, controlled configurations, security policies, secure boot, secure communication channels, resource control, access control, and memory protection).
Operating system security constructs like the access control mechanisms described above significantly improve the overall security posture of the device if and when it becomes compromised. In my next post, I’ll discuss some of the device middleware components that help to keep attackers out of the system and can detect them if and when they do gain access.
For additional information from Wind River, visit us on Facebook.