> This page is for version 10.
> For other versions, use one of these documentation indexes:
> - 11 (default): https://docs.nvidia.com/base-command-manager/product-manuals/11/llms.txt
> - 10: https://docs.nvidia.com/base-command-manager/product-manuals/10/llms.txt

> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.nvidia.com/base-command-manager/product-manuals/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.nvidia.com/base-command-manager/product-manuals/_mcp/server.

# Installing And Configuring SELinux

## 12.1  Introduction

Security-Enhanced Linux (SELinux) can be enabled on selected nodes. If SELinux is enabled on a standard Linux operating system, then it is typically initialized in the kernel when booting from a hard drive. However, in the case of nodes provisioned by NVIDIA Base Command Manager, via PXE boot, the SELinux initialization occurs at the very end of the node installer phase.

SELinux is disabled by default because its security policies are typically customized to the needs of the organization using it. The administrator must therefore decide on appropriate access control security policies. When creating such custom policies, special care should be taken that the `cmd` process is executed in, ideally, an unconfined context.

Before enabling SELinux on a cluster, the administrator is advised to first check that the Linux distribution used offers enterprise support for SELinux-enabled systems. This is because support for SELinux should be provided by the distribution in case of issues.

Enabling SELinux is only advised for BCM if the internal security policies of the organization absolutely require it. This is because it requires custom changes from the administrator. If something is not working right, then the effect of these custom changes on the installation must also be taken into consideration, which can sometimes be difficult.

SELinux is partially managed by BCM and can run on the head and regular nodes. The SELinux settings managed by CMDaemon (via `cmsh` or Base View) should not be managed by directly dealing with the node outside of CMDaemon management, as that can lead to an inconsistent knowledge of the SELinux settings by CMDaemon.

When first configuring SELinux to run with BCM on regular nodes, the nodes should be configured with permissive mode to ensure that the nodes work with applications. Troubleshooting permissive mode so that enforcing mode can be enabled is outside the scope of BCM support, unless the issue is demonstrably a BCM-related issue.

## 12.2  Enabling SELinux On RHEL8, Rocky 9

### 12.2.1  Setting SELinux Parameters

The `selinuxsettings` mode is available at node, category, or partition level.

**Example**

```bash
[root@basecm10 ~]# cmsh
[basecm10]% device use node001
[basecm10->device[node001]]% selinuxsettings
[basecm10->device[node001]->selinuxsettings]% show
Parameter                        Value
-------------------------------- ------------------------------------------------
Initialize                       yes
Revision
Reboot after context restore     no
Allow NFS home directories       yes
Context action auto install      always
Context action full install      always
Context action nosync install    always
Mode                             permissive
Policy                           targeted
Key value settings               <submode>
```

The `Mode` can be set to `permissive`, `enforcing` or `disabled`. When starting the use of SELinux and establishing policies, it should be set to `permissive` to begin with, so that troubleshooting issues to do with running applications with `enforcing` mode can be examined.

The default SELinux configuration parameters are in `/cm/node-installer/scripts/node-installer.conf`, and that file remains unchanged by `cmsh` settings changes. The values of SELinux configuration parameters used from that file are however overridden by the corresponding `cmsh` settings.

For multiarch/multidistro configurations the `node-installer` path in the preceding session takes the form: `/cm/node-installer-`*\<distribution>-\<architecture>*`/scripts/node-installer.conf`. The values for \<*distribution*> and \<*architecture*> can take the values outlined on ([here](/admin/softwareimagemanagement#1171-the-cm-image-tool)).

### 12.2.2  Setting Up On The Head Node

The following procedure can be run on both head nodes to configure SELinux on Rocky 9, so that the SELinux enforcing mode is enabled:

```bash
[root@basecm10 ~]# cmsh
[basecm10]% device use master
[basecm10->device[basecm10]]% selinuxsettings
[basecm10->device[basecm10]->selinuxsettings]% set mode enforcing
[basecm10->device*[basecm10*]->selinuxsettings*]% commit
[basecm10->device[basecm10]->selinuxsettings]% quit
```

```bash
[root@basecm10 ~]# touch /.autorelabel
[root@basecm10 ~]# reboot
...
[root@basecm10 ~]# getenforce
Enforcing
```

### 12.2.3  Setting Up On The Regular Nodes

A similar pattern can be repeated on the regular nodes.

#### 12.2.3.1  Configuring The SELinux Settings

The SELinux settings can be configured at partition, category, or node level.

Nodes that are to use SELinux can be placed in a category, `secategory`. The `secategory` category can be created by cloning it from the `default` category that comes with a newly-installed cluster:

**Example**

```bash
[root@basecm10 ~]# cmsh
[basecm10]% category
[basecm10->category]% list
Name (key)               Software image           Nodes
------------------------ ------------------------ --------
default                  default-image            4
[basecm10->category]% clone default secategory; commit
```

The SELinux settings can then be configured for the newly-cloned category.

**Example**

```bash
[basecm10->category]% use secategory; selinuxsettings
[basecm10->category[secategory]->selinuxsettings]% keyvaluesettings
[basecm10->category*[secategory*]->selinuxsettings*->keyvaluesettings*]% set domain_can_mmap_files 1
[basecm10->category*[secategory*]->selinuxsettings*->keyvaluesettings*]% exit
[basecm10->category*[secategory*]->selinuxsettings*]% set mode<tab><tab>
disabled    enforcing   permissive
[basecm10->category*[secategory*]->selinuxsettings*]% set mode permissive    #for now, to debug apps
[basecm10->category*[secategory*]->selinuxsettings*]% commit
```

The `domain_can_mmap_files` boolean setting is needed to allow SELinux policies to revalidate some kinds of file access in memory.

#### 12.2.3.2  Configuring The SELinux Image To Be Used

**The problem with SELinux file contexts on the node when again provisioning an image:** If the image that is used to provision the node still has the old file attributes, and if the provisioning mode is FULL or AUTO [(section 5.4.4 of the *Administrator Manual*)](/admin/provisioning#544-determining-install-mode-type-and-execution-mode), then image sync during node-installer provisioning results in reverting the SELinux file contexts that have been set up on the running node back to the old state.

Thus, for FULL or AUTO provisioning modes, if `default-image` has no SELinux file security contexts, then the SELinux file security contexts vanish after the node comes back up after a reboot.

**Creating a new image and using `setfiles` to set up SELinux file contexts on the new image:** One good way to have a node come up with SELinux file contexts, is to set up the image that is provisioned so that the image has the contexts already.

This can be configured by first cloning the image, with:

**Example**

```bash
[basecm10->category[secategory]->selinuxsettings]% softwareimage
[basecm10->softwareimage]% list
Name (key)           Path                          Kernel version                Nodes
-------------------- ----------------------------- ----------------------------- --------
default-image        /cm/images/default-image      5.14.0-284.11.1.el9_2.x86_64  5
[basecm10->softwareimage]% clone default-image selinux-image; commit
...
...[notice] basecm10: Initial ramdisk for image selinux-image was generated successfully
```

Then, after `selinux-image` has been generated, the contexts can be set up in the new image with the SELinux `setfiles` command, using the `-r` option to set the root path:

**Example**

```bash
[basecm10->softwareimage]% quit
[root@basecm10 ~]# setfiles -r /cm/images/selinux-image \
    /etc/selinux/targeted/contexts/files/file_contexts /cm/images/selinux-image/
[root@basecm10 ~]# setfiles -r /cm/images/selinux-image \
    /etc/selinux/targeted/contexts/files/file_contexts.local /cm/images/selinux-image/
```

If the image is updated in the future with new packages, or new files, then the `setfiles` commands in the preceding example must be run again to set the file contexts.

**Organizing the nodes and setting them up with the newly-created SELinux image:** Nodes in the category can be listed with:

```bash
[basecm10->category[secategory]]% listnodes
    ...lists the nodes in that category...
```

Nodes can be placed in the category from `device` mode. For example, `node001`, `node002`, and `node003` can be configured with:

```bash
[basecm10->category[secategory]]% device
[basecm10->device]% foreach -n node001..node003 (set category secategory)
```

If the nodes in the category `secategory` are to run file systems with SELinux file contexts, then the image generated for this earlier on, `selinux-image`, can be committed to that category with:

**Example**

```bash
[basecm10->category[secategory]]% set softwareimage selinux-image
[basecm10->category*[secategory*]]% commit
```

#### 12.2.3.3  Booting The Image For SELinux On The Regular Node

The category can then be rebooted to check that all is working correctly.

**Example**

```bash
[basecm10->category[secategory]]% device reboot -c secategory
Reboot in progress for: node001..node003
...
    ...reboot takes place...
[basecm10->category[secategory]]% !ssh node001 "getenforce"
Permissive
[basecm10->category[secategory]]% !ssh node001 "ls -Z"
```

```bash
system_u:object_r:admin_home_t:s0 original-ks.cfg
system_u:object_r:admin_home_t:s0 rpmbuild
```