How-To Docs

Solaris Role-based access control (RBAC)

This document demonstrates the use of Solaris RBAC with Quest Authentication Services.

What is Role-based access control?

Sun Solaris 10's role-based access control (RBAC) and privileges provide a more secure alternative to superuser. A more detailed description can be found in System administration guide: Security Services.

Essentially, Solaris now has a rights database and records which users have been granted those rights (called a rights profile). Secondly, they add some pseudo users (role accounts) that have been pre-bound to particular rights (e.g. operator) with the intention that a logged in user can access specific, dangerous rights when they need to via su. This is very much like sudo and Microsoft's existing AD rights system with its builtin security accounts.

Quest has successfuly tested RBAC with Quest Authentication Services in the following scenarios:

Demonstration: Unix-enabled user with local RBAC role account

This demonstration assumes that Quest Authentication Services is installed and working and that an account johnf exists and is unix-enabled Active Directory user. To install and configure Quest Authentication Services, please see the Quest Authentication Services Solutions Guide. The RBAC role account test in this case is a local account (not an AD account) and is created during step 2.

1. Create the Listings profile

First, an example RBAC profile called Listings is created for the ls command. This will allow our normal johnf user account to run the ls command as root. This is done by editing the exec_attr and prof_attr database files: 

# grep Listings /etc/security/exec_attr
Listings:suser:cmd:::/usr/bin/ls:uid=0

# grep Listings /etc/security/prof_attr
Listings:::Using the ls command:

2. Create the test role account

Next, the local role account named test is created using the roleadd command. 

# roleadd -m -P "Listings" test
# passwd test
Password for test:
Confirm password for test:

# grep test /etc/passwd
test:x:3001:1::/home/test:/bin/pfsh

3. Associate Unix-enabled user johnf with role test

Next, associate the user (johnf) with the role account (test) by editing /etc/user_attr: 

# grep test /etc/user_attr
test::::type=role;profiles=Listings
johnf::::type=normal;roles=test

4. Test ls as Unix-enabled user johnf and then as role test

First, demonstrate that the johnf account is an Active Directory user account: 

bash-2.03$ id
uid=1038(johnf) gid=1000(vintela)
bash-2.03$ grep johnf /etc/passwd

There are no matching entries in the local /etc/passwd file, because johnf is a unix-enabled AD user, provided via Quest Authentication Services. We can use vastool to list unix-enabled AD users and groups: 

bash-2.03$ /opt/quest/bin/vastool list users | grep johnf
johnf@vintela.com:VAS:1038:1000:John Fred:/home/johnf:/bin/bash

Now, we try, as johnf to list a protected directory (/tmp/SECURE), previously created by root: 

bash-2.03$ cd /tmp
bash-2.03$ ls -l
total 1840
drwx------   2 root     other        268 Dec 13 11:00 SECURE
bash-2.03$ ls -l SECURE
SECURE: Permission denied
total 16

An error is returned because the johnf user does not have appropriate permissions to view the /tmp/SECURE directory. Next, we use su to access the role account which has just enough privileges: 

bash-2.03$ su test
Password:
$ ls -l /tmp/SECURE
total 928
-rwx------   1 root     other     465408 Dec 13 10:59 sudo-1.6.8p1-sol8-sparc-local

The role account, test, has appropriate permissions to view the contents of the /tmp/SECURE directory, although not enough to read the files that are inside it.

Demonstration: Unix-enabled user with Unix-enabled RBAC role account

This section demonstrates Unix-enabled users using an RBAC role account that is also a unix-enabled Active Directory account.

As above, we assume Quest Authentication Services is installed and working with the unix-enabled AD user account (johnf). However, this time the RBAC role account (test) is also a unix-enabled AD user. (We deleted the previous local test account and added a test account to Active Directory using vastool.)

1. Create the Listings profile

For this demonstration, the same Listings profile as above was created for running the ls command with elevated privileges. 

# grep Listings /etc/security/exec_attr
Listings:suser:cmd:::/usr/bin/ls:uid=0
# grep Listings /etc/security/prof_attr
Listings:::Using the ls command:

2. The test and johnf accounts are both Unix-enabled user accounts

The user account and the role account are Unix-enabled AD users as can be verified with vastool list: 

# /opt/quest/bin/vastool list users | grep johnf
johnf@vintela.com:VAS:1038:1000:John Fred:/home/johnf:/bin/bash
# /opt/quest/bin/vastool list users | grep test
test@vintela.com:VAS:1078:1000:Test Role Account:/home/test:/bin/pfsh

Note: The role account's login shell must be /bin/pfsh. This can be set through the User properties tab in Active Directory. If for some reason you can't change the role account's shell you can do the equivalent by configuring Quest Authentication Services' user-override file for the role account on the local host: 

# cat /etc/opt/quest/user-override
test::::::/bin/pfsh

3. Associate Unix-enabled user johnf with role test

Associate the user (johnf) with the role account (test) by editing the user_attr database file: 

# grep test /etc/user_attr
test::::type=role;profiles=Listings
johnf::::type=normal;roles=test

4. Test ls as Unix-enabled user johnf and then role test

Testing out the new Listings rights using the Unix-enabled user and Unix-enabled role accounts: 

bash-2.03$ id
uid=1038(johnf) gid=1000(vintela)
bash-2.03$ cd /tmp
bash-2.03$ ls -l
total 1840
drwx------   2 root     other        268 Dec 13 11:00 SECURE
bash-2.03$ ls -l SECURE
SECURE: Permission denied
total 16

bash-2.03$ su test
Password:
$ ls -l /tmp/SECURE
total 928
-rwx------   1 root     other     465408 Dec 13 10:59 sudo-1.6.8p1-sol8-sparc-local
This demonstrates that the Unix-enabled user has su'd to the Unix-enabled role account test and now has appropriate permissions to view the /tmp/SECURE directory.

— J Fehrenbach and D Leonard, 2005