Introduction to permissions

In this new mini-series, requested by one of our readers, we’re going to take a look at how to troubleshoot permissions. To start, let’s take a step back and discuss what permissions are, the various models, types of accounts that are affected, and the principle that should drive all permission-setting: least privilege.

Permissions and rights go hand-in-hand, and are managed by some form of access control system. Some users will have administrative permissions, while most will not. Let’s first take a look at the access control systems commonly deployed and how they stack up.

RBAC/MAC/DAC

There are many different models of permissioning in computer operating systems and applications. All of these are access control systems, hence the A and the C in their acronyms. Role-Based Access Control systems operate around the concept of roles. You grant certain permissions to a role, and then you assign that role to one or more users based on what their job or responsibilities are. In Mandatory Access Control systems, the operating system restricts a subject from performing an operation on a target. Rules are used to evaluate when an operator attempts an action on a target and either permits or denies that action. Mandatory Access Control systems use centrally managed policies put in place by a security administrator. You can encounter MAC in the kernel of the operating system, within Database Management Systems, and elsewhere. Discretionary Access Control systems work in a similar fashion, but users can make discretionary decisions to allow an action to take place. As an example, consider User Account Control in Windows. Even if you have admin rights on your computer, you will be prompted to confirm certain actions.

Superuser accounts

All computer systems have superuser accounts. These are the most privileged accounts and set rights and permissions for all others. In Windows, the superuser account is called “Administrator,” and while you can rename this account, the concept is that the Administrator account (note the capital A) is the account with full and unfettered access to all data and the ability to make all necessary configuration changes. Microsoft products can include other superuser accounts. SQL has either the SystemAttendent (SA) or database owner (dBO) account while Exchange has the role (see RBAC above) Exchange Organization Administrators. In BSD, Unix, and most Linux systems, the superuser is called “root.” Novell’s “admin” or “supervisor” accounts were their superuser, and OpenVMS used “system.”

Regular user accounts

Everyone else is a regular user. Every person should have their own unique user account with credentials known to no one else. These accounts can be granted permissions to data and other resources, but use caution when doing so. Regular user accounts should be used for the day-to-day operations users will need to do as a part of their normal job. If a regular user must also have admin-level permissions to something for special purposes, like configuration or maintenance, it is best to provide them with a second account that is distinct from their regular user account. That way, they can log onto their workstation and do their normal work as a regular user, and have an account with additional permissions when they must do admin-level work.

Least Privilege

When it comes to assigning permissions, there is one rule that resonates with all security professionals across the board. It’s called “Least Privilege” and what it means, in short, is to grant the lowest level of privileges or the least permissions necessary for a user to do what they need to do. The most common application of this is when you do NOT grant users administrative rights to their workstations. If all the software they need will be provided for them, and they do not have the permissions needed to make changes or install additional software, you tend to find that this workstation remains much more stable. It also can help prevent malware from gaining a foothold on your network since it executes with the permissions of the user, and if the users have no permissions, it cannot spread.

In the file system, if a user needs to be able to read a file, grant them only READ permissions. If they need to edit, then grant them CHANGE permissions. Only if they need to grant permissions to others should you (in Windows) grant them FULL CONTROL. More on these, and the *nix equivalents, in the next post.