Less known Solaris features...

But root wasn´t alone. root had servants called daemons. Some of one them needed divine powers to do their daily job. But root was an undividable being. So the servants had to work with the powers of root. But the servants wasn´t as perfect as root: Some of the servants started to do everything mere mortals said to them if they only said more than a certain amount of prayers at once.

One day, the world of root experienced a large disaster, the negation of beeing. Top became bottom, left became right, the monster of erem-ef anhilitated much of the world. But it got even stranger. root destroyed it´s own world, and by the power of root the destruction was complete.

Then there was a FLASH. The world restarted, root got a second attempt to reign his world. But this time, it would be different world.

Superuser
The old model of rights in a unix systems is based on a duality. There is the superuser and the normal user. The normal users have a restriced set of rights in the system, the superuser has an unrestricted set of rights. To modify the system, a normal user has to login as root directly or assume the rights of root (by su -). But such a user has unrestricted access to system. Often this isn´t desirable. Why should you enable an operator to modify a system, when all he or she has do to on the system is creating some users from time to time. You´ve trained him to do useradd or passwd, but it´s a Windows admin who doesn´t know anything about beeing an Unix admin. What do you do when he gets to curious. He needs root privileges to create a user or change a password. You need some mechanisms to limit this operator.

But it´s get more problematic. Programs have to modify the system to work. A webserver is a nice example. It uses port 80. Ports beneath port number 1024 have a special meaning. They are privileged ports. You need special rights to modify the structures of the system to listen to the port 80. A normal user doesn´t have this rights. So the webserver has to be started as root. The children of this process drop the rights of root by running with a normal user. But there is this single instance of the program with all the rights of the user. This process has much rights than needed, a possible attack vector for malicous users.

This led to the development to differet models of handling the rights of users in the system: Privileges and Role Based Access Control.

Least privileges
There is a concept in security. It´s called least privileges. You give someone only least amount of privileges, only enough to do it´s tasks. An example of the real world. You won´t give the janitor the master key for all the rooms on the campus, when all he has to do is working in Building C. The other way round: There are some trusted people who have access to all rooms in case of emergency.

You have the same concept in computer security. Everyone should have only the least amount of privileges in the system to do it´s job. The concept of the superuser doesn´t match to this. It´s an all or nothing. You are an ordinary user with basic privileges or you are an user with unrestricted rights. There is nothing in between. There is no least privileges in this concept.

Role Based Access Control
The example with the key for the janitors is a good example. Let´s imagine a large campus. You have janitors responsible for the plumbing (let´s call them Lenny and Carl), for the park (let´s call him Homer), for the security system (let´s call Marge, Lenny helps from time to time).

These roles have different sets of privileges: For example the plumbing janitor has access to all rooms of the heating system. The janitor for the park has only access to the garage with the lawnmover and the cafeteria and the janitor for the security system.

When they start to work in their job, they assume a role. From the privilege perspective it´s not important who is the person, but what role the person has assumed. Lenny punches the clock and assumes the role of the plumbing janitor for the next 8 hours. And while he is doing it´s job he uses the privileges inherent to the role. But he has to do tasks in his office or in his workshop. It´s his own room, so he doesn´t need the privileges. He doesn´t need the special privileges.

Role Based Access Control is quite similar. You login to the system, and then you start work. You read your emails (no special privileges needed), you find an email "Create user xy45345. Your Boss". Okay, now you need special privileges. You assume the role of an User Administrator create the user. Job done, you don´t need the privileges anymore. You leave the role and write the "Job done" mail to your boss with your normal users.

Role Based Access Control is all about this: Defining roles, giving them privileges and assigning users to this roles.

Privileges
I´ve used the word quite often in the article so far. What is a privilege. A privilege is the right to do something. For example, having the keys for the control panel of the heating system.

Unix users are nothing different. Every user has privileges in a unix system. A normal user has the privilege to open, close, read write and delete files when he his allowed to do this (Because he created it, because he belongs to the same group as the create of the file or the creator gave everybody the right to do it). This looks normal to you, but it´s privilege based on the login credentials you gave to system. You don´t have the privilege to read all files on the system or to use a port number 1024.

Every thing done in the system is based on this privileges. Solaris seperated the tasks into many privilege sets. At the moment, there are 70 different privileges in the system. The difference between the normal user is that the users has only a basic set, the root has all.

But it hasn´t to be this way. Privileges and users aren´t connected with each other. You can give any user the power of the root user, and restrict the privileges of the root user. It´s just our binary compatibility guarantee that mandates that the standard configuration of the system resembles the superuser model. There are application out there, which assume that only the root user or the uid 0 as unrestricted rights and exit when they are started with a different user.

RBAC and Privileges in Solaris
Both features have their root in the Trusted Solaris development. Trusted Solaris was a version of Solaris to ensure highest security standards. Today, these mechanisms are part of the normal Solaris in conjunction with the Trusted Extentions. So RBAC is a really old feature: It´s in Solaris since version 8 (published in 2000). Privileges found their way into the generic Solaris with the first availability of Solaris 10 in February 2005.