DDN BLOG

What are SELinux and MLS?

SELinux provides a mechanism in Linux for supporting Mandatory Access Control (MAC) policies. When a MAC policy is enforced, the operating system’s (OS) kernel defines application rights, firewalling applications from compromising the entire system. And users do not have the ability to override the policy.

Lustre MLS Diagram 1

So, the first purpose of SELinux is to protect the OS from privilege escalation. To that extent, SELinux defines confined and unconfined domains for processes and users. Each process, user and file is assigned a security context, and rules define the allowed operations by processes and users on files.

The other purpose of SELinux can be to protect data sensitivity. And this is where Multi-Level Security (MLS) comes into play. MLS works on top of SELinux, by defining the concept of security levels in addition to domains. Each process, user and file is assigned a security level, and the Bell-LaPadula model states that processes and users can read the same or lower security level, but can only write to their own or higher security level.

Data Flows MLS Systems

Note that most Linux distributions like RedHat and CentOS implement the Bell-LaPadula model with an MLS policy that adds the concept of write equality. It means processes and users can write only to their own level.

How do SELinux and MLS work with Lustre?

From a file system perspective, the security context of files must be stored permanently. Lustre makes use of the security.selinux extended attributed on files to hold this information.

From EXAScaler® 3, SELinux is supported on Lustre client side. All you have to do to have MAC and MLS on Lustre is to enforce the appropriate SELinux policy (as provided by the Linux distribution) on all Lustre clients. No SELinux is required on Lustre server side.

Because Lustre is a distributed file system, the specificity when using MLS is that Lustre really needs to make sure data is always accessed by nodes with SELinux MLS policy properly enforced. Otherwise, data is not protected. It means Lustre has to check that SELinux is properly enforced on client side, with the right, unaltered policy.

DDN engineering has implemented this control, and it is available as a proof of concept. The SELinux client status check is carried out for every file access, as seen from the MDS perspective. If SELinux is not enforced as expected on a client, the server denies its access to Lustre.

What is the performance impact?

SELinux MLS arbitration is exercised for every file access, not for every chunk of data read from or written to files. So there is no impact on bandwidth performance. However, metadata performance is affected as follows:

  • Create performance decreases by 5%;
  • Stat performance drops by 30%;
  • Remove performance decreases by 5%.

Impact on create and remove is quite modest, thanks to a Lustre optimization that avoids sending multiple requests per file access. The impact on stat is more noticeable, because Lustre cannot avoid sending a preliminary request to the MDS server to retrieve the file’s security context, before sending the actual stat request if SELinux has allowed it. With information from the additional SELinux client status checking feature, we observe an extra metadata performance penalty of around 3%.

Want to learn more about the latest DDN MLS developments in Lustre? Visit us at booth #1325 at SC17 or click here to arrange a time to meet at the show.

  • Sebastien Buisson