Quest Software (logo)

How-To Docs

Solaris Role-based access control (RBAC)

This document demonstrates the use of Solaris RBAC with VAS.

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.

Vintela has successfuly tested RBAC with VAS in the following scenarios:

Demonstration: VAS user with local RBAC role account

This demonstration assumes that VAS is installed and working and that an account johnf exists and is unix-enabled Active Directory user. To install and configure VAS, please see the Vintela Authentication Services Install 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 VAS 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 VAS 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 VAS. We can use vastool to list unix-enabled AD users and groups: 

bash-2.03$ /opt/vas/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: VAS user with VAS RBAC role account

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

As above, we assume VAS 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 VAS user accounts

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

# /opt/vas/bin/vastool list users | grep johnf
johnf@vintela.com:VAS:1038:1000:John Fred:/home/johnf:/bin/bash
# /opt/vas/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 VAS's user-override file for the role account on the local host: 

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

3. Associate VAS 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 VAS user johnf and then role test

Testing out the new Listings rights using the VAS user and VAS 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 VAS user has su'd to the VAS role account test and now has appropriate permissions to view the /tmp/SECURE directory.

— J Fehrenbach and D Leonard, 2005