5 Using Role-Based Access Control

This chapter describes how to use role-based access control (RBAC) and the required setup for Oracle Solaris and Linux OS where privileges are available.

Overview of Role-Based Access Control

Role-based access control (RBAC), a feature in Oracle Solaris and Linux, permit non-privileged users to have access to certain privileged functionality, under certain specified circumstances. At a minimum, in Solaris, you can grant the equivalent of setuid root to a particular program, but only when run by a certain user. RBAC enables you to fine-tune access to privileges so that they are available in a restricted environment and only when needed.

In addition, Oracle Solaris includes privileges that give finer-grained access so that a process that requires elevated access can be granted just the minimum access necessary to satisfy its needs without having to use the traditional UID 0 full-access. For example, a program that needs to bind to a privileged port (typically one with a port number that is less than 1024, such as port 25 for SMTP) would have needed root access just for that one activity. With privileges, the program can use the net_privaddr privilege for Solaris and cap_net_bind_service capability for Linux to grant the access needed to bind to the port without having full root access. By compartmentalizing privileged functions, security is greatly enhanced.

You can use RBAC for both methods, and each improves Oracle Communications Messaging Server security.

Theory of Operations

Role-based access control is managed through several files that are located in the /etc and /etc/security directories. You first create a profile that defines the new access that can be granted to the Messaging Server user account. Then you list all the special access that is granted to that profile. Finally, the Messaging Server user account is given access to the new profile.

The special access permitted by the profile is managed through intermediate commands that run the programs with the defined access. The pfexec(1) command is generally responsible for running a program that can then be given elevated access. pfexec is used by the Messaging Server start-msg, stop-msg, and imsimta (through the imtacli program) commands, and the job_controller, to take advantage of role-based access controls.

For more information about role-based access controls, see rbac(5).

Setting Up and Using RBAC for Solaris

Caution:

Implementing role-based access controls involves modifying system files that provide security definitions for the operating system and incorrect modifications may result in potential problems.

The following steps make direct modifications to files in the /etc/security directly, which can also be made by using the Oracle Solaris Management Console (smc(1m)).

Assumptions in the Examples: The following example commands assume that the Messaging Server is installed in the /opt/sun/comms/messaging64 directory and that the Messaging Server processes are using mailsrv as the Unix user.

Copy MessagingServer_home/examples/rbac/MessagingServer.html to the /usr/lib/help/profiles/locale/C directory. This file is referenced by the Messaging Server profile definition. For example:
```
cp /opt/sun/comms/messaging64/examples/rbac/MessagingServer.html /usr/lib/help/profiles/locale/C
```
Append the contents of MessagingServer_home/examples/rbac/prof_attr.example to /etc/security/prof_attr. This is the Messaging Server profile definition.
```
cat /opt/sun/comms/messaging64/examples/rbac/prof_attr.example >> /etc/security/prof_attr
```
Edit MessagingServer_home/examples/rbac/exec_attr.example to replace msg.RootPath with the actual path for your Messaging Server installation. For this example, instances of msg.RootPath are replaced with /opt/sun/comms/messaging64.
Append the contents of the edited MessagingServer_home/examples/rbac/exec_attr.example to /etc/security/exec_attr. This defines the special permissions granted to the Messaging Server profile.
```
cat /opt/sun/comms/messaging64/examples/rbac/exec_attr.example >> /etc/security/exec_attr
```
Modify the user account used by the Messaging Server to have access to this new profile.
```
usermod -P 'Oracle Communications Messaging Server' mailsrv
```
Modify the dispatcher process privilege, so that the dispatcher is able to successfully start. Edit the /etc/security/exec_attr file and add proc_taskid, for example:
```
Oracle Communications Messaging Server:solaris:cmd:::/opt/sun/comms/messaging64/lib/dispatcher:privs=net_privaddr,proc_taskid
```
Set the rbac option to 1 to fully enable RBAC usage. For example:
```
msconfig set rbac 1
msconfig show rbac
role.base.rbac = 1
```

Once the RBAC has been set up, the Messaging Server user has sufficient access so as not to require being run as root, to use the following commands:

start-msg
stop-msg
imsimta restart | shutdown | startup | stop

Setting Up and Using RBAC for Linux

Messaging Server uses privileged ports. Therefore, the processes that non-root users start cannot bind with these ports. To allow a non-root user to perform operations on Messaging Server, you must set the cap_net_bind_service capability to the effective and permitted set for executable files. Then executable files acquire the capability and provide permissions to bind to the privileged ports. These elevated privileges allow non-root users to perform operations on Messaging Server.

The following example shows setting up cap_net_bind_service with effective and permitted set to the imapd executable file:

/usr/sbin/setcap cap_net_bind_service+ep MessagingServer_home/lib/imapd

For more information on permitted and effective set, see https://man7.org/linux/man-pages/man7/capabilities.7.html">>.

See "Messaging Server Privileges and Executable Files" for information on executable files and privileges.

Non-root users can perform the following Messaging Server operations by obtaining appropriate capabilities on Linux OS:

Start Messaging Server
Stop Messaging Server
Set various msconfig options
Execute imsimta commands

After elevating the privileges of executable files, the dynamic linker/loader or ld.so does not link with libraries in an untrusted path which is the location where a non-root user has set up Messaging Server. If a non-root user wants to run such executable files, the non-root user should add the Messaging Server library path to ld.so trusted path.

Configuring Non-Root Users with Messaging Server

You must elevate port-specific privileges to executable files to configure non-root users to start Messaging Server services.

Prerequisites

Table 5-1 lists the OS and platform compatibility requirements to configure non-root users with Messaging Server on Linux OS.

Table 5-1 Operating system and platform compatibility

Operating System	Supported versions	Minimal Kernel version
Oracle Linux 6	8.0.2.4	2.2
Oracle Linux 7	8.0.2.4 and 8.1.0.1	2.2

To configure non-root users with Messaging Server:

Log in as root.
Install Messaging Server where a non-root user is the owner.
Configure Messaging Server with user name of the non-root user who wants to set up RBAC configuration.
Set the rbac option to 1 to enable RBAC usage. For example:
```
./msconfig set rbac 1
```
Set the file capabilities as a root user. For more information on file capabilities, see http://man7.org/linux/man-pages/man7/capabilities.7.html.
In the /etc/ld.so.conf.d/ location, create the ucsmsld.conf file.
Add the MessegingServer_home/lib path as a root user in the ucsmsld.conf file.

Note:
By default, the lib location of Messaging Server is /opt/sun/comms/messaging64/lib.
Run ldconfig to add the Messaging Server library path to dynamic linker trusted path.
Log in as a non-root user and execute the following command to start all the processes that are assigned to the non-root user:

MessegingServer_home/bin/start-msg

Messaging Server Privileges and Executable Files

Messaging Server executable files installed under non-root users directory must possess Linux capabilities to start the processes.

Table 5-2 lists the Messaging Server executable files for which the privileges have to be raised by setting Linux capabilities.

Table 5-2 Executable Files and privileges

Executable File	Privilege
AService	cap_net_bind_service
dispatcher	cap_net_bind_service
imapd	cap_net_bind_service
popd	cap_net_bind_service

Note:

If you use the pipe channel, the pipe_master executable requires the following capabilities to get the privilege: cap_dac_override, cap_fowner, and cap_setuid.

Reference Information

For more information about role-based access controls, see the following sources:

Oracle Solaris 10 documentation: System Administration Guide: Security Services (Roles, Rights Profiles, and Privileges)
man pages: smc(1M), usermod(1M), prof_attr(4), exec_attr(4), privileges(5), rbac(5)