Operating systems (OSs) make access control decisions using configuration metadata, such as access tokens, security descriptors, capability lists, and access control lists (ACLs). The metadata is stored in different formats and can be manipulated in a variety of ways, directly influencing what is perceived as access control behavior. Existing interfaces to query and manipulate the metadata are generally low-level and do not allow software developers to specify information-flow goals and verify their intent effectively. As an example, in feature-rich operating systems such as MICROSOFT WINDOWS XP or Security Enhanced Linux (SELinux), there can be a complex interplay between different access control security mechanisms. As an example, access checks the OS performs based on a user's access token and a resource's security descriptor can be quite involved. An access token may contain group membership information that is inherited from a parent object. The token could have attributes that may not readily indicate a user's access privileges because these access privileges are inherited. Security descriptors identify security-related properties, such as access control permissions.
Users generally cannot directly specify simple information-flow policies, such as confidentiality, integrity, and privilege-escalation. As an example, a system administrator may desire to ensure various access control properties, such as integrity or confidentiality. When an OS offers integrity, a lower-privileged process cannot modify data used by a higher-privileged process. When an OS offers confidentiality, security-sensitive information is not accessible to lower-privileged processes. To enforce these conceptually simple access controls, users may need to correctly configure a variety of low-level access settings. This configuration can be complex and, if not correctly implemented, may not be correctly enforced.
Moreover, some security-related dependencies may not be directly visible. As an example, some OSs may implicitly decide whether a user is a member of an “Interactive Users” group when the user logs in. Consequently, the user's access control permissions may not be discernible until the user logs in.
In some OSs, the protection model is rigid and restricted to fully privileged kernel mode and a lesser-privileged user mode. Because this type of protection model cannot be easily changed, many applications run with far more privileges than a task may need.
As a result of these difficulties, system developers may inadvertently create access vulnerabilities, such as by configuring overly permissive ACLs and assigning higher privileges than a task may need. Moreover, when a new application is installed or configured, it can be difficult to analyze the impact of its permission and privilege settings and select a configuration that best minimizes the risk of an information-flow vulnerability.