Less known Solaris features...

• Rights: A right is the description, to execute an executable as an privileged user.For example the permission to execute the command reboot as root.
• 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:

$ roles
No roles

Let´s use the standard example for RBAC: reboot the system. To do this task, you need to be root.

$ /usr/sbin/reboot
reboot: permission denied

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.

# roleadd -m -d /export/home/reboot reboot
64 blocks

After creating the role, you have to assign a role password.

# passwd reboot
New Password:
Re-enter new Password:
passwd: password successfully changed for reboot

Okay, when you look into the /etc/passwd, you see a quite normal user account.

# grep reboot /etc/passwd
reboot:x:101:1::/export/home/reboot:/bin/pfsh

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:

# usermod -R reboot jmoekamp
UX: usermod: jmoekamp is currently logged in, some changes may not take effect until next login.

The RBAC system stores the role assignments in the /etc/user_attr file

# grep "jmoekamp" /etc/user_attr
jmoekamp::::type=normal;roles=reboot

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

# echo "REBOOT:::profile to reboot:help=reboot.html" >> /etc/security/prof_attr

Okay, now assign the role profile REBOOT to the role reboot

# rolemod -P REBOOT reboot

The information of this assignment is stored in the /etc/usr. Let´s have a look into it:

# grep reboot /etc/user_attr
reboot::::type=role;profiles=REBOOT
jmoekamp::::type=normal;roles=reboot

But this isn´t enough: The profile is empty. You have to assign some administrative command to it.

# echo "REBOOT:suser:cmd:::/usr/sbin/reboot:euid=0" >> /etc/security/exec_attr

Using using the new role
Okay, let´s check the role assignments.

$ roles
reboot

We have still no rights to execute the reboot command.

$ /usr/sbin/reboot
reboot: permission denied

But now we assume the reboot role.

$ su reboot
Password:

And as you see ...

$ /usr/sbin/reboot
Connection to 10.211.55.3 closed by remote host.
Connection to 10.211.55.3 closed.

Connection terminates, systems reboots.

Authorisations
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:

jmoekamp$ /usr/sbin/svcadm -v disable -s apache2
svcadm: svc:/network/http:apache2: Couldn't modify "general" property group (permission denied).

Wouldn´t it be nice, to have an authorisation that enables an regular user to restart it? Okay, no problem. Let´s create one:

$ su root
# echo "solaris.smf.manage.apache/server:::Apache Server management::" >> /etc/security/auth_attr

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:

# usermod -A solaris.smf.manage.apache/server jmoekamp
UX: usermod: jmoekamp is currently logged in, some changes may not take effect until next login.

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.

# svcprop -p general apache2
general/enabled boolean false
general/entity_stability astring Evolving

No authorisation configured. Okay ... let´s add the authorisation we´ve defined before:

svccfg -s apache2 setprop general/action_authorization=astring: 'solaris.smf.manage.apache/server'

Check the properties again:

# svcadm refresh apache2
# svcprop -p general apache2
general/enabled boolean false
general/action_authorization astring solaris.smf.manage.apache/server
general/entity_stability astring Evolving

Okay, a short test. Exit your root shell and login as the regular user you have assigned the authorisation.

bash-3.2$ svcs apache2
STATE STIME FMRI
disabled 22:49:51 svc:/network/http:apache2

Okay, i can view the status of the service. Now i try to start it.

bash-3.2$ /usr/sbin/svcadm enable apache2
svcadm: svc:/network/http:apache2: Permission denied.

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.

# svccfg -s apache2 setprop general/value_authorization=astring: 'solaris.smf.manage.apache/server'

With the value authorisation SMF allows you to change the state of the service. Try it again.

bash-3.2$ /usr/sbin/svcadm enable apache2
bash-3.2$

Cool, isn´t it ... try this with init.d ...

Predefined roles
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"

Software Installation:::Add application software to the system:help=RtSoftwareInstall.html; auths=solaris.admin.prodreg.read, solaris.admin.prodreg.modify, solaris.admin.prodreg.delete,solaris.admin.dcmgr.admin, solaris.admin.dcmgr.read,solaris.admin.patchmgr.*

This role profile has already some predefined command, that need special security attributes to succeed:

Software Installation:solaris:act:::Open;*;JAVA_BYTE_CODE;*;*:uid=0;gid=2
Software Installation:suser:cmd:::/usr/bin/ln:euid=0
Software Installation:suser:cmd:::/usr/bin/pkginfo:uid=0
Software Installation:suser:cmd:::/usr/bin/pkgmk:uid=0
Software Installation:suser:cmd:::/usr/bin/pkgparam:uid=0
Software Installation:suser:cmd:::/usr/bin/pkgproto:uid=0
Software Installation:suser:cmd:::/usr/bin/pkgtrans:uid=0
Software Installation:suser:cmd:::/usr/bin/prodreg:uid=0
Software Installation:suser:cmd:::/usr/ccs/bin/make:euid=0
Software Installation:suser:cmd:::/usr/sbin/install:euid=0
Software Installation:suser:cmd:::/usr/sbin/patchadd:uid=0
Software Installation:suser:cmd:::/usr/sbin/patchrm:uid=0
Software Installation:suser:cmd:::/usr/sbin/pkgadd:uid=0;gid=bin
Software Installation:suser:cmd:::/usr/sbin/pkgask:uid=0
Software Installation:suser:cmd:::/usr/sbin/pkgchk:uid=0
Software Installation:suser:cmd:::/usr/sbin/pkgrm:uid=0;gid=bin

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.