Embedded Systems Security - Part 2: Access control and capabilities

David Kleidermacher and Mike Kleidermacher -February 11, 2013

Editor's Note: Embedded Systems Security aims for a comprehensive, systems view of security: hardware, platform software (such as operating systems and hypervisors), software development process, data protection protocols (both networking and storage), and cryptography. In this excerpt, the authors offer an in-depth look at the role of the operating system in secure embedded systems. In part 1, the authors offer an in-depth look at the role of the operating system in secure embedded systems. In this installment, the authors discuss how an OS provides access control for ensuring process security. In part 3, the authors examine the use of hypervisors in implementing system virtualization. In part 4, the authors review the security pitfalls and trends in embedded I/O virtualization.

Adapted from "Embedded Systems Security" by David Kleidermacher and Mike Kleidermacher (Newnes)

2.5 Access Control and Capabilities
All operating systems provide some form of access control for processes. Embedded systems contain a plethora of resources: communications, files, processes, various devices, memory, and more. An important goal of security design is to ensure that applications are able to access the resources they need and are disallowed to access resources they do not need.

Key Point
Many security problems are caused by poor access control architecture and/or implementation within the operating system or improper use of access control facilities by the embedded system designer.

At a coarse level, access control policies can be divided into two classes: discretionary access control (DAC) and mandatory access control (MAC). Both have their place in secure embedded systems design.

An example of a DAC is a UNIX file: a process or thread can, at its sole discretion, modify the permissions on a file it owns, thereby permitting access to the file by another process in the system. DACs are useful for some kinds of objects in some kinds of systems. But an operating system must go one big step further for security and provide MAC of critical system objects. A MAC is managed by the system and cannot be modified by users or processes. For example, let’s consider a communications device managed by a call processing application. The system designer must be able to configure the system such that the call processing application, and only the call processing application, has access to this device. Another application in the system cannot dynamically request and obtain access to this device. And the call processing program cannot dynamically provide access to the device to any other application in the system. The access control is enforced by the kernel, is non-bypassable by application code, and is thus mandatory. Mandatory access control provides guarantees. Discretionary access controls are only as effective as the applications using them.

The combination of mandatory and discretionary access controls is often required to implement sophisticated embedded systems. For example, mandatory access controls may be used to divide system resources across multiple security domains such that no application within a security domain may access unauthorized resources. However, within a security domain, discretionary access controls may be used to provide a more flexible sharing of resources.

DACs and MACs can come in many flavors; access control decisions may be based on a practically infinite combination of subject (user/process) and object (device) attributes, roles, and states.

2.5.1 Case Study: Secure Web Browser
Access control enforces the principle of least authority over the processes and resources in an embedded system. When high-profile security vulnerabilities caused by software flaws in common operating systems such as Windows are published, we often make the false assumption that the software vulnerability deserves all the blame. In truth, it is the system’s lack of access authority restriction that often is the culprit. A software flaw, properly contained, may have no security impact whatsoever. Sadly, vulnerabilities in an application are often exploited by attackers to gain access to resources that the application should never have had in the first place.

Next: Title-1

Loading comments...

Write a Comment

To comment please Log In