The management of administrative privileges in Oracle Solaris

Oracle Solaris presents an interesting approach for distributing root privileges to Solaris users. Their approach has been stable since it was defined in 2003. The approach adopted the RBAC model for defining roles that Solaris users can assume. Solaris considers the root account as a role that users can take. In Solaris, roles are user accounts that cannot log in; thus, each role has an associated password that can be shared by a group of users that share the same role.

From the kernel point of view, Solaris defines four sets of privileges for each process: Effective set, permitted set, Inheritable set, and Limit set. Effective and permitted sets are handled in the same manner as Linux. However, Inheritable and Limit sets are calculated differently during exec() call. In particular, Solaris authorizes the inheritance of privileges after an exec() call, even when the executable doesn’t have privileges stored in its binary. More interestingly, instead of storing privileges in the extended attributes of executables, Solaris provides administrators with a set of central databases (user_attr, prof_attr, and exec_attr) for storing privileges and roles, and user attributes. 

Under Solaris, administrators should define the privileges they can grant to the right profile using the profiles command. They can then assign the right profile to roles or users using rolemod and usermod commands. Users can obtain these privileges when logged in if the right profile is assigned to them directly or when they assume roles if the right profile is granted to roles.

In addition, Solaris allows administrators to define the programs (e.g.,/usr/sbin/snoop) or even scripts that a user/role can use with the privileges defined in the right profile. Administrators can also define the resource that can be used with the privilege. For example, administrators can limit the use of net_privaddr (which allows any program to bind to a port less than 1024) to port 80 and TCP protocols. 

For more clarification, we have implemented our Python script scenario in Solaris 11.3. We have first defined the right profile for an HTTP server python script and the privileges to attribute to this script (net_privaddr and file_dac_execute).  

Then we assign the right profile to a role (testrole) using the command rolemod. And finally, we let the user test assume the role testrole. 

Interestingly, testrole permits only to execute httpserver4.py, the script declared in the right profile, but not httppython4.py, which is a copy of httpserver4.py, but not declared in the right profile. 

 

In addition, it is possible to precise the resources on which privileges can be used. For example, the privilege net_privaddr permits to our script to bind to any port less than 1024. We may refine this privilege by allowing our script to bind only at port 80. We can also restrict the privilege file_dac_execute to execute only our script.

 

Finally, Solaris provides users the command ppriv (ppriv –De command) for knowing which privileges programs ask for. This is an important feature that is not present in Linux, but developed by a RootAsRole using eBPF https://github.com/SamerW/RootAsRole.