A Look at IAM in Red Hat Enterprise Linux

This is a trimmed down version of an article I published on LinkedIn on Jun 11, 2020 (https://www.linkedin.com/pulse/look-iam-red-hat-enterprise-linux-david-edwards-iamdavid-/).

For a recent engagement I had to ‘page back in’ long-forgotten aspects of identity and access management (IAM) for Unix/Linux, specifically the Red Hat Enterprise Linux (RHEL) operating system. I couldn’t find a comprehensive guide to all the components affecting IAM for RHEL, thus this article. It is not meant to be an in-depth exploration of capabilities, but rather an overview of the key capabilities, what functions they perform and how they interact.

This article will build up a complete IAM picture by looking at RHEL native security and RHEL centralized security. It will assume a basic knowledge of Unix/Linux security. There are links to RHEL documentation and other relevant information.

RHEL Native Security

Red Hat Enterprise Linux (RHEL) has various inbuilt security controls: discretionary access controls like users, groups and filesystem security, and user escalation mechanisms; and mandatory access controls provided with security enhanced Linux (SELinux). 

There are also security modules or products that can be installed into/onto the base OS to provide enhanced security. For example, the SeOS (Secure OS) and Tivoli Access Manager for Operating System (TAMOS) products that were popular for enhanced Unix/Linux security a decade ago. We will not cover them in this article.

Users, Groups and Filesystem Security and User Escalation

From the very first Unix there has been filesystem security tied to users and groups. Most of us learned about this in school or university and it’s still there in RHEL Linux. Users and user groups are defined in files (/etc/passwd, /etc/group) and all files have access permissions tied to them via user owner, group owner and others (anyone) permissions. Everything in Unix/Linux is a file. When one goes to read/write/execute a file the OS checks whether the user is allowed to perform it directly, via one of their groups, or via the world level permissions. There is far more complexity, like the use of shadow files and other capabilities (like setuid/setgid), but that’s the gist of it. 

RHEL also supports an Access Control List (ACL) mechanism where additional controls can be applied on top of the usual user/group permissions. For example, you could have ‘rw-‘ permission for one user/group, ‘r—’ permission to another.

The challenge with this model is that root (and equivalent) accounts can bypass the filesystem security. Also, some user functions require root, so you either need to login as root (and share the password with others) or use one of the escalation mechanisms; “su” or “sudo”. The ‘switch user’ (or ‘substitute user’, su) command will allow a user to become another user, such as root, as long as they know the password of that user (same password sharing challenge). With su one can perform any function that assumed user can, so represents a risk for someone switching to root.

The better option is the ‘superuser do’ (or ‘substitute user do’, sudo) command. It allows you to assume another user and execute commands as that user, but by validating using your own password (risk of shared password gone). If you use an Apple Mac you will have used sudo every time you do something where the system prompts you for your password (like installing an app). The use of sudo allows control on what can be executed by the user as the assumed user. 

These native security aspects are shown in the following figure.

There is one component we have not discussed, the SSSD (System Security Services Daemon), which is related to user authentication and optionally authorization. With a native RHEL installation (not using any external directories or identity management systems) the SSSD will defer all user authentication to local authentication (e.g. userid/password must match the entry in /etc/passwd) and leave any authorization to the native tools. We will talk more about SSSD later in this article.

For more information on the topics above:

• User and group accounts: “Getting started with managing user accounts” and “Managing user and group accounts”
• Access Control Lists (ACLs): “Access control list”
• Filesystem permissions: “Managing file permissions”
• Sudo: “Managing sudo access” and “Wikipedia sudo article”

This completes the native RHEL identity and access capabilities.

SELinux

Security-enhanced Linux was originally developed by the NSA and Red Hat to address the shortfalls of native Linux security. It is a Linux kernel security module, so can intercept and apply controls to any call irrespective of the user (controls applied to root and all other users). 

It implements Mandatory Access Control, or MAC (“Getting started with SELinux” has good introduction of DAC vs. MAC). A Linux kernel integrating SELinux enforces mandatory access control policies that confine user programs and system services, as well as access to files and network resources. Limiting privilege to the minimum required to work reduces or eliminates the ability of these programs and daemons to cause harm if faulty or compromised (Wikipedia). The following is a very simplified explanation of SELinux.

SELinux consists of policy with rules to dictate who can access what. It also uses contexts to identify resources used in a transaction (e.g. the user running in the shell will have a context and the file being accessed will have a context). This consists of the SELinux user, the SELinux role, SELinux type and optionally a sensitivity. You will see the type of object in the label suffix; _u for SELinux user, _r for SELinux role and _t for SELinux type. This is not enforced, just a convention.

The SELinux user is not the Linux user (i.e. not someone defined in /etc/passwd). A SELinux user can be thought of as a user group (or job role?) where many Linux users (or logins) are mapped to a single SELinux user. A Linux user can only be mapped to a single SELinux user at a time. You might have a set of SELinux users like user_u, staff_u, sysadm_u and system_u.

There may be multiple SELinux roles a SELinux user can be associated with and SELinux allows users to switch role (i.e. the context will contain a different role). For example, you may have roles like dba_r, staff_r, sysadm_r, and user_r. These may be mapped in a M:M relationship with SELinux users.

The type, or domain, defines the types (classes) of resources involved. It may represent a user, a file or other resources. Whilst SELinux users and SELinux roles are arbitrary and defined by the security administrator, SELinux type classes are based on the operating system resources (like user, file, filesystem, socket, tcp_socket etc.). 

Policy rules will include ‘allow’ statements defining the SELinux types and operations permitted. For example, the following rules will allow users with a type of user_t to execute files of type bin_t and user_bin_t. 

allow user_t bin_t:file { execute };
allow user_t user_bin_t:file { execute };

For SELinux to allow an action, both the source context (e.g. the user context, like user_t) and the target context (such as the file context, like lib_t) must be allowed in a policy rule. The combination of source and target contexts is called the access vector. Note that SELinux policy rules are applied after native (DAC) policy. If a user does not have permission to access something via the filesystem permissions, SELinux cannot override that to grant access.

There is far more complexity than covered above, but the key takeaways are:

1. There are definitions internal to SELinux that define users (user groups), roles and object types, and policies to allow access
2. A Linux user (login) can be mapped to a single SELinux user, but a SELinux user may have multiple Linux users (logins) mapped to it
3. A SELinux user may be allowed to use different SELinux roles to access different SELinux types (e.g. different sets of permissions on resources based on role) and if there are multiple roles allowed, the user can switch role (switch context).

These are shown in the following figure.

Thus, a complex MAC policy can be built and enforced on a Linux system such as RHEL. The following figure shows the two models (MAC and DAC) side-by-side.

There is an administration console for SELinux and command line tools (‘semanage’).

For more information about SELinux, the Wikipedia page and the Gentoo wiki are good starting points. There’s also a great article using diagrams with a dog eating analogy at opensource.com. The SELinux user/Linux user relationship is explained in another Gentoo wiki article. From a Red Hat perspective there is the Using SELinux guide and also Getting Started with SELinux in the RHEL System Design Guide.

Centralised RHEL Security

The focus on local users and security policy works with a small number of systems but doesn’t scale. If you have many systems or dynamic systems (such as elasticity applied to cloud services) you need a central persistent store to authenticate against and manage policy. This concept has been around for decades with implementations like the Network Information Service (NIS) leveraging a central directory and use of Pluggable Authentication Modules (PAM) for remote authentication.

The two RedHat mechanisms for this involve use of the Red Hat Directory Server and/or the Red Hat Identity Manager.

System Security Services Daemon (SSSD)

The System Security Services Daemon (SSSD) is a system service to access remote directories and authentication mechanisms. It connects a local system (an SSSD client) to an external back-end system (a provider). This provides the SSSD client with access to identity and authentication remote services using an SSSD provider. For example, these remote services include: an LDAP directory like RedHat Directory Server, an Identity Management (IdM, like RedHat Identity Manager) or Active Directory (AD) domain, or a Kerberos realm. 

It can perform the role of identity provider (for user information), authentication provider (for authentication requests) and authorization provider (for authorization requests). It can also remotely access sudo configuration (i.e. sudo config stored in LDAP or AD and cached locally in SSSD). Use of SSSD is key to centralising IAM, but what it can do will depend on the central service it is connected to. See the product documentation for details.

RedHat Directory Server

The RedHat Directory Server (RHDS) is an LDAP-compliant directory. It’s a separately licensed RedHat component based on the 389 Directory Server from the Fedora Project. 

The directory can hold users and authentication information (passwords, certificates) and the RHEL instances can authenticate users against it using LDAP. This uses the SSSD (System Security Services Daemon) to connect to the directory and authenticate the user. The user does not need to be defined locally (does not exist in the /etc/passwd file). It is functionally equivalent to the IBM Security Directory Server.

The directory supports Active Directory synchronization so it may be feasible to have AD users logging into RHEL via RHDS, but there are better mechanisms for this (like native SSSD integration with AD).

See the RedHat Directory Server product documentation for more information.

Red Hat Identity Manager

Red Hat Identity Manager (RH IdM) has been called “Active Directory for Linux”. It is based on the Fedora FreeIPA project. From an identity governance and administration (IGA) functional perspective, it sits between a directory and a full-blown identity management product and is designed to provide an integrated identity service for a range of clients, including Linux, Mac, and Windows.

It is based on the FreeIPA project and combines a number of opensource components to provide a range of services:

• LDAP – an LDAP directory (389 Directory Server) is embedded
• Kerberos – KDC (MIT Kerberos) for Kerberos key management and single signon
• DNS – BIND (bind-dyndb-ldap) for domain name services
• PKI – Red Hat Certificate System (Dogtag certificate system) provides public key infrastructure for certificate management
• NTP – Network Time Protocol service for time sync
• A web-based management front-end running on Apache

From an identity and access management perspective, RH IdM is providing a number of capabilities;

• Remote authentication of users,
• Establishing a trust domain with Active Directory so users/groups can be defined in AD but referenced (via Kerberos) from RHEL,
• Centralised management of users and groups, 
• Centralised management of user to SELinux user mapping, and
• Centralised management and storage of sudo configuration

It provides a web interface, Ansible playbooks and command line tools to create and manage users and groups. This information is stored in the LDAP directory, and accessed as part of the authentication and authorization via SSSD from a RHEL system. This means users and groups can be stored centrally rather than on each RHEL system (in /etc/passwd and /etc/group). The use of Kerberos means that once a user has authenticated to the Linux system in a domain, they can single signon (SSO) to other services. It can also manage public SSH keys for users.

If SELinux has been enabled and SELinux user, role and type policies defined, RH IdM can manage the mapping between Linux users (logins) and SELinux users. RH IdM does not centrally manage the SELinux objects, relationships and policy rules. 

Finally, RH IdM can be a central management point for sudo policy, by providing a central store of sudo configuration. The SSSD in RHEL system will check and cache sudo policy for local sudo requests.

For more information see the FreeIPA website, the Fedora FreeIPA documentation and the Red Hat product documentation; Planning Identity Management, Configuring and Managing Identity Management (including Chapter 24. Granting SUDO Access to an IdM User on an IdM Client), and Linux Domain Identity, Authentication, and Policy Guide Chapter 32. Defining SELinux User Maps.