Glenn Faden's Blog

  • July 7, 2015

Applying Rights Profiles to RAD Modules in Oracle Solaris 11.3

Guest Author

The Remote Administration Daemon (RAD) is a key foundation of the system management architecture, enabling developers to write RAD modules that interface with different sub-subsystems within the Oracle Solaris operating system. Administrators can use RAD to locally and remotely interact with systems.  Oracle Solaris 11.3 adds additional fine-grained controls to specify the security attributes with which these modules are executed.

Each RAD module is independently specified via an Abstract Data Representation (ADR) and provides a unique set of methods and properties. The client-side bindings for Python, C, and Java are auto-generated. Server-side modules are shared objects that can be written in C or Python.  When a client application connects to the local or remote RAD service, a new RAD slave process is started to execute remote procedure calls on behalf of the user and client.

These RAD slaves are started with the credentials of the user who initiated the RAD connection. RAD slaves that are initiated by normal user connections run as the user with only basic privileges; connections initiated by root run with all privileges. If RAD module methods are implemented by executing subcommands, the process attributes of these commands can be specified in RBAC profiles which are associated with the user. However, if the RAD method calls library functions which require privilege, it was previously necessary to connect as root or to subsequently assume the root role.

Oracle Solaris 11.3 provides additional RBAC controls that eliminate the need to connect as root. Previously the full set of RAD modules were loaded into each RAD slave so that all modules shared the same process credentials. This has been changed in Oracle Solaris 11.3 so that each module now runs in its own slave process. As a result, RBAC profile entries can be specified for each RAD module. Although this change is transparent to the client-side application, it provides greater flexibility for the delegation of administrative rights and roles.

For example, the User Manager GUI is a Visual Panels application, written in Java, that relies on the RAD usermgr module to create and modify accounts. This RAD module is written in C, and relies on existing CLIs like useradd(1M) and usermod(1M) for most of its processing. Since these commands are included in rights profiles like User Management and User Security, user's who have been assigned these profiles can delegate some of their security attributes to existing accounts.

However,  in previous Oracle Solaris releases only the root account could create new accounts or customize the rights profiles of existing accounts. This restriction was a side-effect of the underlying module implementation. For example, the method to create a new account makes direct calls to libpam and libbsm, each of which require additional privileges.

In Oracle Solaris 11.3 the User Security rights profile has an additional entry specifying that mod_usermgr.so.1 runs with euid=0.

 # profiles -p "User Security" info
        name=User Security
        desc=Administer user security

Now users with the User Security profile can use the User Manager GUI to create accounts and to delegate their rights. However, they are still not permitted to assign rights that they don't already have because they lack most of the authorizations required to assign such rights. Only root has those authorizations be default.

 # auths info|grep assign

Note that rights profiles and authorization assignments are associated with the real user ID, not the effective user ID. If the RAD module entry in the profile has been assigned the uid=0, then the module would be granted all authorizations as well as all privileges.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.