This role is not confined by SELinux except by memory protections (for example executable memory protections).

This guide will discuss creation of new roles when these roles do not meet needs.

Creating the Policy for the New Role

This section of the guide discusses the creation of the policy for the roles. These statements should be added to a policy module. See GettingStarted for more information on creating policy modules.

There are several methods for creating roles in Reference Policy. It is best to use Reference Policy templates, as there are several requirements for a user to log in, but they are beyond the scope of this guide.

Roles Similar to Existing Roles

If the role's user domain should be similar to user_r or staff_r, the userdom_unpriv_user_template() template should be used.

userdom_unpriv_user_template(myrole)

If the role's user domain should be similar to sysadm_r, the userdom_admin_user_template() template should be used.

userdom_admin_user_template(myrole)

These both will create role myrole_r and user domain myrole_t. Then rules can subsequently be added to myrole_t to customize it.

Configuring Userland Programs for the New Role

Default Type

The default_type file configure SELinux-aware programs behavior when constructing a context. When the program only is provided with a role, the domain for the new context is selected based on this file. Typically this file is only used by the newrole program. Add the new role:domain combination to the end of this file.

For each service, the order matters. The service will test to see which role:domain combination is valid for the user logging in, and use the first available choice (left to right). So if the SELinux user is allowed user_r and myrole_r, the default will be user_r:user_t when logging in.

You should notice that myrole_r:myrole_t was not added to the remote_login_t or sshd_t lines. This means that if a user with only myrole_t tries to log in via login apps running as remote_login_t or sshd_t it will fail.