Access Control Systems

This is an attempt to understand the need for and context behind SELinux and compare with similar ideas in the software world. Also, the way different approaches are presented is not the only way to do it, just something that made sense to me.

What is Access Control?

Access control is a data security process to manage who is authorized to access resources. It is an unavoidable piece of application security and therefore important to understand for software engineers. There are typically 3 facets of access control:

• Authentication: check if you are the one who say you are. Common mechanisms include OAuth (an API mechanism), LDAP (vendor neutral application mechanism) etc. This is not the major focus of this talk.
• Authorization: check if you are allowed to do a specific thing. We focus on this facet in this write-up.
• Audit: add a data entry with your identity and action for later analysis. In the rest of this discussion, we don’t talk much about this.

Types

A question to clarify first is who controls access to a specific resource. There are 2 options (more details including pros/cons):

1. Owner of the resource. This approach is called discretionary access control. It is not very restrictive as it works based on a person’s own discretion and allows the system owner or administrator complete control over who has access permissions throughout the security system.
2. System or the administrator. This approach is called mandatory access control. This is very stringent as it allows only the system owner or administrator to control and manage the system and access points. In addition, the administrator can only tweak things laid out by the system’s parameters.

The next question to keep in mind is how we manage the linkage among the plethora of users and resources. There are a few options again, 2 important ones are discussed here (more details including pros/cons):

1. Role based access control (RBAC) — here users are grouped into roles and permissions are given only to users. It is an automatable approach because we can leverage the similarities in accesses needed for users. It is much more of a static system.
2. Attribute based access control — here the decision metric is attributes of users and data. It is also automatable, but requires a lot of details to get it right safely. It can be viewed as a very dynamic system.

Now, these 2 are not strictly orthogonal, but it was a helpful way for me to think about what actual systems do. Implementation often use a mix of these approaches to ensure cybersecurity principles such as principle of least privilege (PoLP).

Examples

Traditional Linux Access control

It is definitely a discretionary access control mechanism where the owner of the resource can give anybody permissions to do anything with the resource. It is vaguely role based since groups can be assigned permissions, but that’s about it in the usual implementations. It can be enhanced using frameworks such as PAM, PolicyKit and SELinux.

IAM in GCP

Identity and access management (IAM) is a centralized and consistent way to manage user identities. It has a lot of attributes of a role-based access control since there are clear notions of roles, permissions and users. But, IAM Conditions gives it the facilities of an attribute based access control system. It is more mandatory than discretionary though since owners, though exists as a concept, are at project level and owners can’t really assign permissions without any care in the world. In short, IAM has way too many features to be called strictly one type (an interesting Reddit discussion).

SELinux

It is most definitely a mandatory access control since users can’t disable it. This means that even if your process runs as root, SELinux will be in effect, and may block you from doing stuff. It also has properties of RBAC since SELinux policies make clear use of roles and actions each role can do with each type based on the resource’s security context.

A bit more about SELinux

Security-Enhanced Linux is a set of kernel-level security features in the Linux operating system, provides more fine-grained access control models for resources. It was originally developed by National Security Agency (NSA) as a series of patches to the Linux kernel using Linux Security Modules (LSM).

• This is one of the most common ways of avoiding limitations of discretionary access control in a typical Linux system. For example, RedHat and Rocky Linux install SELinux by default.
• Resources in the early point is meant in the broad sense of the word: files, processes, network sockets, and more. Every resource gets a SELinux security context in the form of user:role:type:range. Files have extended attributes (run ls -Z). Others have their context in the kernel like users, processes and network sockets.
• A user is mapped to a SELinux user, which defines the maximum clearance of that user. The SELinux user is allowed one or more roles. Types are the most important part of a context as all rules are based on types.
• The range field of a context is an advanced setting that assigns a range of sensitivities. It is used to implement fancier security structures such as Multi-Level Security (MLS) which are irrelevant for most SELinux usecases.
• Security policy consists of numerous set of rules. A simple example of a rule is allow init_t user_home_t:file read;. This means that processes with security context init_t are allowed to read files that have the type user_home_t. Similarly, to allow group admins to grant permissions to passwd files, use allow group_admins:file { read write execute } /etc/passwd;.
• Users vs Processes is an interesting idea in the context of SELinux. One way to think about it is: where the Unix file permissions protect users’ and the system files from modification by unintended users, SELinux type enforcing protects resources from modification or usage by unintended processes. But, SELinux can control the permissions granted to users or groups as well as manage the privileges and restrictions of individual processes. Eg: alice has permissions to read files in the /home/alice directory. When alice starts a text editor process, that process will inherit her permissions and can typically access those files. However, SELinux can restrict the process from accessing resources, even if alice has permissions to do so.
• Reference: an in-depth comparison.