Access Control

One of the biggest challenges in computer security is preventing one program from interfering with another. For instance, you don’t want a virus to be able to steal the passwords from your browser. For this reason, operating-systems implement protection mechanisms that enable the isolation of multiple processes and restrict access to data.

For a start we’ll see what are the basic mechanisms implemented in Linux. Then we’ll introduce an enhanced security solution and show how it can be used to harden the system.

Traditional Access Control

In Linux, the kernel is the program that has unrestricted access to the whole machine. All other programs run as a specific identity and have their access mediated by the kernel. Access decisions are made on the basis of the userid/groupid associated with the program. If the user is root (userid = 0), access is always granted by the kernel. Users usually have a default group, but they may belong to several additional groups. By joining an existing group, a user inherits the permissions it grants.

Unix permissions

Using the ls -l command we can display the Unix permissions set to a file or a directory:

The first column rw-rw-r-- is made of 3 triads defining the permissions granted to the owner, to the group and to all the other users, respectively. Each permission triad is commonly made up of the following characters:

  • r: the file can be read / the directory’s contents can be shown
  • w: the file file can be modified / the directory’s contents can be modified
  • x: the file can be executed / the directory can be traversed
  • s: the file is setuid if s is found in the user triad (setgid if u is in the group triad). Implies x. Enables the file to run with the privileges of its owner

Third and fourth columns correspond to the user and group which own the file. Notice that modern Linux distributions, upon user creation, usually add a group to the system with the same name of the user being added and set this group as the primary user’s group.

As mentioned before, the set of permissions of an user includes the permissions assigned to his groups.

Unix permissions can be altered using the chmod command (using the symbolic mode or the numeric one), whilst the owner can be set using chown.

Access Control Lists (ACL)

Suppose we are in a shared hosting system where users are allowed to host personal websites in their home directories. The webroot of the user lavish is the world-readable directory /home/lavish/webroot. The home directory of lavish can be accessed only by the user itself:

In order to allow the webserver process (running as nginx:nginx) to access the webroot directory, we could make even the /home/lavish world-traversable using chmod o+x. Sadly, by doing so we would enable everyone (not just the webserver) to read files in the user home directory just by knowing the path name, including the sensitive file personal_notes.txt!

Access Control Lists provide an additional, more fine grained permission mechanism for files and directories. With ACLs it is possible to define different permissions on a per-user/per-group basis. They have higher priority over Unix permissions and provide inheritance of attributes from directories to files. Going back to the webserver example, we can make good use of the ACLs by granting the x permission on /home/lavish/ only to the nginx user!

The command setfacl is used to define ACLs, while getfacl allows to display them. To provide an example, we first create a test file in the current directory and print its ACL

Now we change the ACL so that the user r1x can read and write the newly created file

The mask entry reported by the getfacl output is called the effective rights mask. This entry limits the effective rights that can be granted to the user and group ACL. By tightening the mask further, we revoke the write permission previously granted to the user r1x

To remove an ACL from a file one can use the -b option

See man getfacl and man setfacl for further details. Also notice how the output of ls -l is affected by the presence of an ACL: in addition to the + symbol, the file permission bits reported by ls may not correspond to the actual Unix permissions. To understand the correspondance between ACL entries and file permission bits read the relevant section in the manual page of acl by typing man 5 acl.

Downsides of the traditional access control mechanism

There are four main problems with the traditional Unix access control system.

First of all, the root user. An attacker gaining root privileges is all-powerful and might even alter the system logs to hide his malicious activities or to implant fake audit trails. It is possible, however, to limit the need of setuid root binaries by giving to specific processes a subset of superuser permissions via Linux capabilities.

Second, an application running on behalf of a user has access to all the resources owned by that user. Think about a browser, which is an application perpetually running potentially-malicious code, and a sensitive resource like a private ssh RSA key

Browsers, indeed, implement layered sandboxes to prevent unauthorized access to system resources. Check the Linux sandboxing approach implemented by Google Chromium for further details.

Third is the lack of a centralised access control policy. Permissions are attached to resources making impossible for a system administrator to fully understand the security implications of all the single permissions leaving space for backdoors.

Last, users can take their own access decisions about their resources. If this could be a non-issue for a single-user Desktop computer, it is a problem of crucial importance when the user is a member of an organization and is entrusted with sensitive files. For this reason, the standard Unix access control system is called Discretionary, as opposed to Mandatory Access Control systems where a security policy is enforced independently of user actions.

Role-Based Access Control

RBAC is a widespread security model defined around roles and privileges. The central idea in the RBAC model is to factor the assignment of access rights into two steps, separating the distribution of permissions to system-specific roles, from the assignment of users to roles, so as to simplify the overall access control management task.

Grsecurity RBAC

Grsecurity is a patch for the Linux kernel, providing extensive protection against a wide range of security threats. It implements a mandatory RBAC-like system on top of standard Linux access control system. The access control system is managed through a policy file which is basically a set of human readable system-wide rules. To make it easier to create a secure policy, Grsecurity provides the ability to learn how the system functions and build a least-privilege policy based on the collected data.

More in detail, the policy is made up of the following entities:

  • roles
    • special roles, specific to Grsecurity (usually more privileged roles) with higher priority
    • user roles, an abstraction over the traditional Unix users, automatically applied when a process has a particular user id
    • group roles, an abstraction over the traditional Unix groups, automatically applied when a process has a particular group id and no user roles are defined for the current user of the process
    • default role, a role which is impersonated when nothing else applies
  • subjects
    • directories, binaries or scripts, are always associated with a role and define a set of permissions for the objects accessed by the matching processes
  • objects
    • files and resources

An example of a policy is provided below

There are two roles defined in this policy: lavish of type user and tutor, which is a special one. The role lavish is allowed to impersonate the role tutor. Subjects are defined within roles: there are three subjects defined for the lavish role: / which is the mandatory default subject, /bin/cat and /bin/su. The latter two subjects inherit the permissions defined for the / subject, but can redefine some objects to ovveride the operations assigned to them. For instance, /bin/su is allowed to read and write /dev/null, but cannot execute any binary under /bin. On the other hand, the role lavish has no visibility of the contents of the /dais directory, but can read and modify the /dais/acadia_calendar.txt file.

Notice that, besides of the centralized policy, RBAC provides several advantages over the standard Unix access control system:

  • it allows to remove privileges from root, by defining specialized administrative roles;
  • different processes started by the same user can be assigned to different subjects, each one with a specific set of permissions;
  • users are not allowed to change the policy, in this way it would be possible for the policy manager to avoid declassification of sensitive data.

Additionally, RBAC enables to control the impersonation of special roles through an additional authentication step and also features a declarative way to define the allowed transitions to Linux users and groups.

Working with Grsecurity RBAC

The administration utility for Grsecurity RBAC is gradm. The access control system requires the following passwords to be set before being enabled: the RBAC administration password, the special role admin password, and the special role shutdown password.

It is now possible to create a least-privilege policy by enabling RBAC in full-system learning mode

When the training phase is completed, it is possible to disable RBAC and generate the policy

The policy can now be manually simplified and made more general. The access control mechanism can now be enforced using


Leave a Reply

Your email address will not be published. Required fields are marked *