Less known Solaris features: RBAC and Privileges - Part 2: Role based access control
Some basic terms
As usual the world of RBAC has some special terms. Before using it, i´m want to explain the jargon. I copy the exact definition from the RBAC manual:
- Rights: A right is the description, to execute an executable as an privileged user.For example the permission to execute the command
- Authorisation: A permission that enables a user or role to perform a class of actions that could affect security. For example, security policy at installation gives ordinary users the solaris.device.cdrw authorization. This authorization enables users to read and write to a CD-ROM device
- Right Profiles: A collection of administrative capabilities that can be assigned to a role or to a user. A rights profile can consist of authorizations, of commands with security attributes, and of other rights profiles. Rights profiles offer a convenient way to group security attributes.
- Role: A special identity for running privileged applications. The special identity can be assumed by assigned users only. In a system that is run by roles, superuser is unnecessary. Superuser capabilities are distributed to different roles.
Practical side of RBAC.
After so much theory, let´s work with roles. After installation of a Solaris system there are no rules assigned to a normal user:
Let´s use the standard example for RBAC: reboot the system. To do this task, you need to be root.
You are not allowed to do this. Okay, until now you would give the root account to all people, who have to reboot the system. But why should someone be able to modify users, when all he or she should to is using the reboot command ?
Okay, at first you create a role. As mentioned before, it´s a special user account.
After creating the role, you have to assign a role password.
Okay, when you look into the /etc/passwd, you see a quite normal user account.
There is one important difference. You use a special kind of shell. This shell are called profile shells and have special mechanisms to check executions agains the RBAC databases.
Okay, we´ve created the role, now we have to assign them to a user:
The RBAC system stores the role assignments in the
But at the moment, this role isn´t functional, as this role has no assigned role profile. It´s a role without rights an privileges.
At first, lets create a REBOOT role profile. It´s quite easy. Just a line at the end of
prof_attr. This file stores all the attributes of
Okay, now assign the role profile REBOOT to the role reboot
The information of this assignment is stored in the
/etc/usr. Let´s have a look into it:
But this isn´t enough: The profile is empty. You have to assign some administrative command to it.
Using using the new role
Okay, let´s check the role assignments.
We have still no rights to execute the reboot command.
But now we assume the reboot role.
And as you see …
Connection terminates, systems reboots.
But RBAC can do more for you. There is an additional concept in it: Authorisations. Authorisations is a mechanism that needs support of the applications. This application checks if the user has the nescessary authorisation to use a program. Let´s use the example of the janitor: Rights give him the access to the drilling machine. But this is a rather strange drilling machine. It checks, if the janitor has the permission to drill holes, when he trigger the button. The concept of authorisation is a fine grained system. An application can check for a vast amount of privileges. For example the application can check for the autorisation to modify the configuration, to read the configuration or printing the status. A user can have all this authorisations, none or something in between. It´s like the janitors new power screwdriver. It checks if the janitor has the permission to use it at anticlockwise rotation, the permission to use it at clockwise rotation and the permission to set different speeds of rotation. Using authorisations for Services
Although applications need support to this modell, you can even use it as an admin. SMF has build in support for authorisations. You can assign authorisations to a service. Every role or user with this authorisation is allowed to work with the service (restarting,stop,start,status, …). Let´s use Apache for this example. A normal user has no permission to restart the service:
Wouldn´t it be nice, to have an authorisation that enables an regular user to restart it? Okay, no problem. Let´s create one:
That´s all. Where is the definition of the permission that the authorisation measn? There is no defintion. It´s the job of the application to work with.
Now assign this authorisation to the user:
Okay, but at the moment no one checks for this authorisation, as no application is aware of it. We have to tell SMF to use this authorisation. The authorisations for an SMF servers is part of the general properties of the service. Let´s have a look at the properties of this services.
No authorisation configured. Okay … let´s add the authorisation we´ve defined before:
Check the properties again:
Okay, a short test. Exit your root shell and login as the regular user you have assigned the authorisation.
Okay, i can view the status of the service. Now i try to start it.
What the hell …? No permission to start the service? Yes, enabling the service is not only a method (the start up script), it´s a value of a certain parameter. When you only have the action_authorization you can only do task, that doesn´t change the state of the service. You can restart it (no change of the service properties), but not enable or disable it (a change of the service properties). But this is not a problem. You have to login as root again and assign the the
solaris.smf.manage.apache/server authorisation to the value authorisation.
With the value authorisation SMF allows you to change the state of the service. Try it again.
Cool, isn´t it … try this with init.d … ;)
This was a really simple example. Roles can get really complex. But you don´t have to define all role profiles at your own. For some standard tasks, there are some predefined roles. Just look at the
/etc/security/prof_attr. There are 70 role profiles defined in this file. For example the right profile “Software Installation”
This role profile has already some predefined command, that need special security attributes to succeed:
This is all you need to install software on your system. You can use this predefined role profiles at your will. You don´t have to do define all this stuff on your own.