12. Security Enhanced Linux in VDURA Systems

This chapter explains the VDURA implementation of Security Enhanced Linux (SELinux).

12.1 Terminology

Access Control Mechanism (ACM) is a mechanism that can allow or prevent access by a user or a running process to a file system object such as a file or directory, based upon some criteria. Traditional UNIX permissions bits are a simple form of ACM, while Access Control Lists (ACLs) are a more sophisticated form.

Discretionary Access Control (DAC) is a class of security mechanisms for objects in a file system, such as files, directories and devices, that allows the owner of an object to decide who can access that object. Access to a file system object is granted or revoked at the discretion of the owner of the object. Traditional UNIX file permissions and ACLs are discretionary.

Mandatory Access Control (MAC) is a class of security mechanisms that restricts the level of control that users or running processes have over the file system objects that they create. Unlike in a DAC implementation, where users have full control over their own objects, MAC centralizes control of access decisions for those objects through policies defined by the system’s administrator. It does this by adding additional labels, or categories, to all file system objects and checking whether a given user or process has been granted access to those categories by the system’s administrator before they can interact with those objects.

Multi-Category Security (MCS) is an enhancement to SELinux that allows users to label files with categories. Only users who have been granted access to this category by the system’s administrator can access files labeled with the category, assuming the existing DAC and TE rules also permit access.

Multi-Level Security (MLS) is a specific MAC security scheme. The “multi-level” concept comes from the defense community’s security classifications of Confidential, Secret, and Top Secret forming an increasingly strict hierarchy. MLS is only relevant if a storage system is asked to store content from different levels in the security hierarchy at the same time. It is intended to prevent a user or process that is only allowed to access content in a lower security level from accessing anything in a higher security level.

Role-Based Access Control (RBAC) allows the system’s administrator to establish roles for users and file system objects based on business-functional requirements or similar criteria instead of controlling access purely by permissions associated with each user. For example, an “Operator” role might have permission to backup the data on a storage system but not to change that system’s configuration, while an “Administrator” role might have permission to review and change the configuration of the storage system but not to access the data it contains. Each user account on such a storage system might have one or more associated roles it could perform.

Type Enforcement (TE) is an access control mechanism found in MAC systems, where access decisions are made based on a subject-access-object set of rules that answer the question: “May <subject> do <action> to <object>?”. For example: “May a web server (subject) read (action) files in user X’s home directory (object)?”.

12.2 SELinux Overview

Security Enhanced Linux (SELinux) refers to a Linux system that has been configured to enable a Linux Security Module (LSM) that is built into the Linux kernel. The SELinux subsystem in the kernel is driven by a security policy which is controlled by the system’s administrator and loaded at system boot time. All security-relevant, kernel-level access operations on the system are intercepted by SELinux and examined in the context of the loaded security policy. SELinux answers the question: “May <subject> do <action> to <object>?”. For example: “May a web server (subject) read (action) files in user X’s home directory (object)?”

SELinux implements Mandatory Access Control (MAC). MAC requires that every process and system resource have a special security label called an SELinux context (you may also see this referred to as an SELinux label, security label, or MAC label). An SELinux context is an identifier that abstracts away the details of the security policy and focuses on the security properties of the entity. The SELinux policy uses these contexts in a series of rules that define how users and processes can interact with each other and various system resources. By default, the policy does not allow any interaction unless a rule explicitly grants access.

Note: The VDURA SELinux implementation should not be confused with its other access control mechanisms. PanFS offers two different Discretionary Access Control mechanisms: traditional UNIX permissions bits and Access Control Lists (ACLs).

12.3 PanFS and MAC

Mandatory Access Control (MAC) systems bind security attributes such as SELinux security context labels to objects within a system. These attributes are used with other information in the system to make access control decisions. Today, MAC systems have been mainstreamed in modern operating systems such as Linux, Windows, macOS, and FreeBSD.

The PanFS storage system is MAC-aware and operates in Limited Server Mode, as defined in NFSv4.2 terminology found in IETF RFC 7204. PanFS will store and transmit labels but does not make any assumptions regarding their format or content and will not itself enforce security policies on file system objects. PanFS depends upon the client’s operating system to interpret and enforce the policies that the security labels represent. It will inform client systems when a security label changes for a file the client has open or if it has a copy of that file’s metadata. The client must apply its own policy to file system objects, using the security labels obtained from PanFS.

The following set of features is supported on Linux-based client systems with Linux kernel versions of at least 2.6.25:

• PanFS stores and retrieves MAC labels as requested by a client.
• MAC labels are coherent across multiple client systems just like file system data and metadata. PanFS will notify clients of changes to the MAC label for a file if that client has that file open or has a copy of the metadata for that file.
• PanFS supports mount options that are specific to SELinux (context, rootcontext, fscontext, defcontext) that set some default parameters used by SELinux.
• The same DirectFlow Client operates in both SELinux/non-SELinux environments.
• PanFS supports older DirectFlow Clients without MAC labeling support at the same time as it supports updated DirectFlow Clients that do support MAC labels. Customers are not forced to upgrade their client systems before they can upgrade to a PanFS version that supports SELinux.

12.4 Configuration and Use

SELinux requires security contexts be associated with file system objects to decide whether access is allowed or not, as defined by the security policy. A security context is stored as a string in an Extended Attribute (an xattr) with a predefined and fixed name of security.selinux.

Within SELinux, a security context is represented as a variable-length string that includes either three or four pieces of information: the SELinux user, role, type, and an optional MCS/MLS security level or range. These items are separated by colon characters:

user:role:type[:range]

• User: This string represents SELinux’s identity for a given user. All SELinux policy and MAC mechanisms use this string, which may or may not match the user’s normal login ID. Login IDs from LDAP, Active Directory, or other identity management systems are mapped to SELinux user strings via a configuration file on the client system.
• Role: A role is associated with one or more object types the SELinux user can access. Roles determine what types of objects SELinux users can access.
• Type: When a type is associated with a process, it defines what processes or domains an SELinux user can access. When a type is associated with an object, it defines what access permissions the SELinux user has to that object.
• Range or Level: This feature is only applicable if the policy supports MCS or MLS. The entry can consist of either:
  • A single security level that contains a sensitivity level and zero or more categories, such as s0 or s1:c0, s7:c10.c15.
  • A range that consists of two security levels (low and high) separated by a dash, such as s0 - s15:c0.c1023.

Important: SELinux policy rules are checked after DAC rules. SELinux policy rules are not used if DAC rules deny access first, which means that no SELinux denial is logged if the traditional DAC rules prevent the access attempt.

12.5 Important Considerations

To implement a secure environment using SELinux and PanFS, there are two configuration steps that a system administrator must take.

First, DirectFlow Client access must be restricted to only those IP addresses listed in the DFC exports file in PanFS. That step will prevent client systems that are not using SELinux or that do not respect the security labels from accessing the file system. Allowing other access paths would bypass the SELinux security policies entirely.

Second, remember that PanFS does not take part in access control decisions, but rather supports the SELinux security module in the client’s kernel with label storage and retrieval. Since clients are responsible for enforcing security policy and access control based on MAC labels, it is imperative that all clients that can access PanFS use the same security policies. Specifically, they must all use the same sets of SELinux user, role, type, and range strings, and they must all have the same policies for how those strings are interpreted and applied.