Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-) Softpanorama Search

Solaris 10 Role Based Access Control (RBAC)

Lecture Notes:

The problem with the traditional model is not just that root (superuser) is so powerful, but that a regular user accounts are not powerful enough to fix their own problems.

There were some limited attempts to address this problem in Unix in the past (wheel group and immutable file attributes in BSD, sudo, extended attributes (ACL), etc), but Role Based Access Control (RBAC) as implemented in Solaris 10 is probably the most constructive way to address this complex problem in its entirety.  

RBAC is not a completely new thing. Previous versions of RBAC with more limited capabilities existed for more then ten years in previous versions of Solaris. It was introduced in Trusted Solaris and was later incorporated into the Solaris 8. In was improved and several additional predefined roles were introduced in Solaris 9.  Still they generally fall short of expectations and only Solaris 10 implementation has the qualities necessary for enterprize adoption of this feature.

Among predefined roles that is several that are immediately useful and usable:

1. All Provides a role access to commands without security attributes: all commands that do not need root permission to run in a regular Solaris system (Solaris without RBAC implementation) :
    
2. Primary Administrator Administrator role that is equivalent to the root user.
    
3. System Administrator. Secondary administrators who can administer users (add, remove user accounts, etc). Has privileges solaris.admin.usermgr.read solaris.admin.usermgr.write that provides read/write access to users’ configuration files. Cannot change passwords.
    
4. Operator. Has few security related capabilities but still capable of mounting volumes. Also has solaris.admin.usermgr.read privilege that provides read access to users’ configuration files.
    
5. Basic Solaris User.  Enables users to perform tasks that are not related to security.
    
6. Printer Management. Dedicated to printer administration.

But the original implementation has had severe limitation in defining new roles which blocked wide adoption of this feature: in practice most system commands that were needed for roles should be run as root. Still even the old implementation that exited till Solaris 9 has sudo-style capability of one time assumption of the command with specific (additional) privileges is accomplished by pfexec command.  If the user is assigned "Primary Administrator" profile then pfexec command became almost exact replica of the typical sudo usage. 

Also if role has no password then switch of context does not require additional authentication (only authorized users can assume roles). That can be convenient for some application roles.

There were several problems with early RBAC implementations:

• Limited flexibility in constructing new roles
• Hidden dangers of running selected commands with root privileges (that danger that is typified by sudo).
• Fuzzy interaction of RBAC facility with the extended attributes facility (ACL).
• The four flat flat files that Solaris 8 implementation introduced suggested some questionable quality of engineering.

All-in-all Solaris RBAC until version 10 has limited appeal to most organization and unless there was a stron push from the top was considered by most administrators too complex to be implemented properly. It also has some deficiencies even in comparison with sudo.  The only "cheap and sure"  application in the old RBAC implementation was conversion of root account to role and conversion of  operators to operator roles. Conversion of application-related accounts like oracle into roles was also  possible, but more problematic.

That changed with Solaris 10 when RBAC model was extended with Solaris privileges model. It extended the ability to create new custom roles by assigning very granular privileges to the roles.   Previously such tricks needed heavy usage of ACLs, and as any ACL-based solution were  both expensive and heavy maintenance solutions

There are three distinct properties of roles:

1. A role is not accessible for normal logins (root is a classic example of an account that should not be accessible by normal login; most application accounts fall into the same category)
2. Users can gain access to it only explicitly changing his identity via su command, the activity that is logged and can be checked for compliance.
3. Role account uses a special shell (pfksh or pfsh).  Please note that bash is not on the list :-)

Each user can assume as many roles as is required for him to perform his responsibilities (one at a time) and switch to a particular role for performing a subset of operations that are provided for this role. Theoretically an administrator can map user responsibilities into a set of roles and then grant users the ability to "assume" only those roles that match their job responsibilities. And no user should beg for root access any longer :-)  But the devil is in details: even with Solaris 10 power this easier said then done. Role engineering is a pretty tough subject in itself even if technical capabilities are here and it requires time and money to implement properly. 

Still it looks like Solaris 10 was the first Unix that managed to breaks old Unix dichotomy of "root and everybody else". In this sense Solaris 10 is the first XXI century Unix.   The privilege model that was incorporated in RBAC made it more flexible and useful, surpassing sudo in most respects. One time execution of a command, for example vi, with additional privileges still remains the problem as the command can have a backdoor to shell.  

Like its predecessor sudo, Solaris RBAC provides the ability selectively package superuser privileges  for assignment to user accounts by assigning them packages of the appropriate privileges. For example, the need for root account can be diminished by dividing those capabilities into several packages and assigning them separately to individuals sharing administrative responsibilities (still root remains a very powerful account as it owns most important files).

It might be useful to distinguish between following notions:

• Authorization - A right that is used to grant access to a restricted function
• Profile - A mechanism used for grouping authorizations and commands for subsequent assignment to role or to a user. You can assign one or several profile to role.
• Role - A special type of user account that you cannot login directly, but can only su to it.  It intended for application accounts and sometimes is useful as a container for performing a set of administrative tasks
• Role shell Special shell alias (for example pfksh, instead of ksh) that gives the shell capability to consult RBAC database before execution of the command.  Please note that bash can't be used as role shell.

RBAC relies on a database that consist of four flat files (naming suggests that Microsoft agents penetrated Sun on large scale ;-), as the proper way to group related configuration files in Unix is to use common prefix, like rbas_user, rbac_prof, rbac_exec, rbac_auth, but Unix is flexible and you can create such links and forget about this problem):

• /etc/user_attr (main RBAC file)
• /etc/security/prof_attr (right profile attributes/authorizations)
• /etc/security/exec_attr (profile execution attributes)
• /etc/security/auth_attr (authorization attributes).

As usual syntax is pretty wild and is a testimony that in Sun left hand does not know what right is doing. Essentially this is another mini-language in a family of approximately a hundred mini-languages that Sun boldly introduced for configuration files while naively expecting that administrators say with Solaris no matter what perverse syntax they are using in "yet another configuration file" (TM) :-).   HEre are some details on those configuration files:

1. /etc/user_attr (main RBAC file, essentially the extension of /etc/passwd)

   /etc/user_attr  lists the accounts that are roles, associates regular users with roles. Consists of type of the account (type=) and authorizations list (auth= ) and profiles (profiles=, which is an indirect way to assign authorizations). If type is notmal then the account is a regular traditional Unix account for example:

   root::::type=normal;auth=solaris.*,solaris.grant 

   If type is "role" then this is a new type of account -- role account.  For example:

   datesetter::::type=role;profile=Date Management

   By default all Solaris users are granted  Basic Solaris User profile. The default profile stored in /etc/security/policy.conf is applicable to all accounts that do not have an explicit assignment.
   
   Effective profile for normal users can also be changed, for example for the user Joe Doers the profile can be changed to Log Management:

   doerj::::type=normal;profile=Date Management

2. /etc/security/prof_attr (right profile attributes/authorizations) Associates names of right profiles (or simply profiles, although the tem is confusing)  with the set of authorizations. Only authorizations listed in /etc/security/auth_attr are allowed.

   This is a little bit problematic implementation as right profile is essentially a parameterless macro that is substituted into a predefined set of authorizations. But surprisingly the only form of this macro definition is plain vanilla list. There is no wildcard capabilities of regular expression capabilities in specifying them. Also there is no way to deny certain lower level authorization while granting a higher level authorizations. For example, I cannot specify expressions like (solaris.admin.usermgr.* - solaris.admin.usermgr.write). There is also no possibility to grant global access to a specific operation reading like solaris.*.*.read  In general I see no any attempt to incorporate the access control logistics typical for TCP wrappers, firewalls and similar programs. That makes creation of a profile less flexible then it should be, but hopefully this is not that frequent operation anyway, and you can write Perl scripts that generate any combination of authorizations you want quote easily, so the damage is minor.

   Like I mentioned in my lecture before there are several predefined right profiles (all of the them can be modified by sysadmin):

   • All right profile that provides a role access to commands without security attributes. In a non-RBAC system, these commands would be all commands that do not need root permission to run.
   • Primary Administrator right profile that is designed specifically for the Primary Administrator role. In a non-RBAC system, this role would be equivalent to the root user.
   • System Administrator. right profile that is designed specifically for a junior level System Administrator role. The System Administrator rights profile uses discrete supplementary profiles to create a powerful role.
   • Operator right profile Designed specifically for the Operator role. The Operator rights profile uses a few discrete supplementary profiles to create a basic role.
   • Basic Solaris User right profile that enables users to perform tasks that are not related to security.
   • Printer Management. right profile dedicated to the single area of printer administration.

   Each profile consists of  one or more authorizations, for example:

   Basic Solaris User:::Automatically assigned rights:
   auths=

   solaris.profmgr.read,solaris.jobs.users, solaris.mail.mailq, solaris.admin.usermgr.read, solaris.admin.logsvc.read, solaris.admin.fsmgr.read, solaris.admin.serialmgr.read, solaris.admin.diskmgr.read, solaris.admin.procmgr.user, solaris.compsys.read, solaris.admin.printer.read, solaris.admin.prodreg.read, solaris.admin.dcmgr.read, solaris.snmp.read,solaris.project.read, solaris.admin.patchmgr.read, solaris.network.hosts.read, solaris.admin.volmgr.read;

   profiles=All; help=RtDefault.html

   Notes:

   it uses mnemonic name for a privilege set, not dotted representation. There are many Sun-supplied profiles (30 in Solaris 9), for example:

   • Primary Administrator (profile that permits performing all administrative tasks)
   • Basic Solaris User (Default profile assigned to the new accounts )
   • Operator (Can perform simple administrative tasks).
      
3. /etc/security/exec_attr(profile execution attributes) - this is sudo style file that defines the commands assigned to a profile and under which EUID and EGID. The fields in the /etc/security/exec_attr database are separated by colons:

   name:policy:type:res1:res2:id:attr

   • name The name of the profile. Profile names are case sensitive.
   • policy -- The security policy (priviledge) associated with this entry. In Solaris 9 the suser (superuser policy model) is the only valid policy entry.
   • type The type of entity whose attributes are specified. The only valid type is cmd (command).
   • res1,res2 Reserved for future use.  Reserved for future use.
   • id A string identifying the entity. You can use the asterisk (*) wildcard. Commands should have the full path or a path with a wildcard. To specify arguments, write a script with the arguments, and point the id to the script.
   • attr An optional list of key-value pairs that describes the security attributes to apply to the entity when executed. You can specify zero or more keys. The list of valid key words depends on the policy being enforced. There are four valid keys: euid, uid, egid, and gid.
   • euid and uid – Contain a single user name or a numeric user ID. Commands designated with euid run with the effective UID indicated, which is similar to setting the setuid bit on an executable file. Commands designated with uid run with both the real and effective UIDs set to the UID you specify.
   • egid and gid – Contain a single group name or numeric group ID. Commands designated with egid run with the effective GID indicated, which is similar to setting the setgid bit on an executable file. Commands designated with gid run with both the real and effective GIDs set to the GID you specify.

   For example

   Date Management:suser:cmd:::/usr/bin/date:euid=0

   Adds to the profile "Date Management" the ability to execute command "/usr/bin/date
 
4. /etc/security/auth_attr (authorization attributes)- This is a system generated static file that predefines a hierachical sets of privileges available on a particular system (92 in Solaris 9, 126 in Solaris 10). Privileges (authorizations) are structured like DNS with dots separating each constituent:
    
   • Authorizations for the Solaris OE use solaris as a prefix.
      
   • The suffix indicates what is being authorized, typically the functional area and operation. For example grant or delete or modify.
      
   • When there is no suffix (that is, the authname consists of a prefix, a functional area, and ends with a period), the authname serves as a heading for use by applications in their GUI rather than as an authorization. The authname solaris.printmgr. is an example of a heading.
      
   • When authname ends with the word grant, the authname serves as a grant authorization and lets the user delegate related authorizations (that is, authorizations with the same prefix and functional area) to other users. The authname solaris.printmgr.grant is an example of a grant authorization. It gives the user the right to delegate such authorizations as solaris.printmgr.admin and solaris.printmgr.nobanner to other users.
      
   Only system programmers can add entries to this database. It also identifies the help file that explains a particular privilege set.

   For example:

   solaris.admin.usermgr.:::User Accounts::help=AuthUsermgrHeader.html
   solaris.admin.usermgr.write:::Manage Users::help=AuthUsermgrWrite.html
   solaris.admin.usermgr.read:::View Users and Roles::help=AuthUsermgrRead.html
   solaris.admin.usermgr.pswd:::Change Password::help=AuthUserMgrPswd.html

5. In addition to those four file, /etc/security/policy.conf  lets you grant specific rights profiles and authorizations to all users.  Essentially provides system default authorizations for all users. Entries consist of key-value pairs, for example:

   AUTHS_GRANTED=solaris.device.cdrw
   PROFS_GRANTED=Basic Solaris User

   The solaris.device.cdrw authorization provides access to the cdrw command.

   # grep ’solaris.device.cdrw’
   /etc/security/auth_attr solaris.device.cdrw:::CD-R/RW Recording Authorizations::help=DevCDRW.html

   The Basic Solaris User profile grants users access to all listed authorizations.

Paradoxically RBAC can be more useful for application accounts then to "human" accounts.  That means that for a large organization an optimal plan for conversion to RBAC is first to convert system and applications accounts to roles.

• Among system roles are root and operator. Both roles can (and probably should ) be converted to role even in previous versions of Solaris.
• By application accounts we mean the account used for structuring permissions and launching processes for a particular enterprise software like Oracle, Webshere, Apache, Sendmail, bind, etc) because privileges requirements for those accounts are static.

The main command line tools include:

• roleadd – Adds a role account on the system.
• rolemod – Modifies a role’s login information.
• useradd – Adds a user account on the system.

Additional commands that you can use with RBAC operations.

• auths Displays authorizations for a user.
• pam_roles Identifies the role account management module for the Password Authentication Module (PAM). Checks for authorization to assume a role.
• pfexec Executes commands with the attributes specified in the exec_attr database.
• roles Displays roles granted to a user.
• roleadd Adds a role account to the system.
• roledel Deletes a role’s account from the system.
• rolemod Modifies a role’s account information in the system.

Command that has role relat4ed options:

• useradd Adds a user account to the system. Use the -R option to assign a role to a user’s account.
• userdel Deletes a user’s login from the system.
• usermod Modifies a user’s account information in the system.

Related commands:

• makedbm Makes a dbm file.
• nscd Identifies the name service cache daemon, which is useful for caching the user_attr, prof_attr, and exec_attr databases.

Old News ;-)

[Dec 10, 2006] Sys Admin System Security in SolarisTM 10 Privileges and Zones in Perspective -- Part 1 by Peter van der Weerd

What Is RBAC Again?

A user has two UIDs: a Real UID and an Effective UID. This is not entirely true because Posix and System V Unixes introduced a third UID, the Saved UID. We don't need the Saved UID for this discussion, though.

At login time, both UIDs are identical, based on the entry in the passwd-file. When a user starts a second process, the Effective UID may differ from the Real UID. To accomplish this, a user would typically run the su command. When a regular user with, say UID 2001, runs su, he will be asked for the superuser password, and a new process will be created. This process has Real UID 2001 and Effective UID 0. This means that for the lifetime of this new process, the user runs all his instructions with Effective UID 0. The user will have to know the password of the UID he wants to switch to. Root would be the only one that can switch to a regular user without knowing that user's password. Having to know the other user's password is a major flaw in the use of su.

RBAC combines users, roles, profiles, authorizations, and execute attributes. A user can su to a role, thus enabling himself to perform certain instructions based on the role's profile. The profile is connected to an "execute" right. This execute right is a specific command that will be executed with a specific Effective UID.

It is good practice to connect multiple profiles to one role so as to allow a user to do multiple administration tasks once he has su-ed to that role. As with su, the user must know the password of the role he wants to su to, but his execute rights will be much more limited on the basis of the exec attributes he is entitled to:

User -> Role -> Profile -> Exec Attribute (command with EUID)

Here's an example:

First, a regular user called "baseuser" is created on an x86 machine called "solx":

solx# useradd -m -d /export/home/baseuser baseuser
64 blocks
solx# passwd baseuser
New Password: <password here>
Re-enter new Password: <password again>
passwd: password successfully changed for baseuser
solx# grep baseuser /etc/passwd
baseuser:x:5007:1::/export/home/baseuser:/bin/sh

Second, a role is added to the system:

solx# roleadd -m -d /export/home/reboot reboot 64 blocks
solx# passwd reboot
New Password: <password here>
Re-enter new Password: <password again>
passwd: password successfully changed for reboot
solx# grep reboot /etc/passwd
reboot:x:5008:1::/export/home/reboot:/bin/pfsh

Notice the shell (/bin/pfsh). This shell enables a user to execute a command in a profile. This is not a shell you can login to.

Connect the user "baseuser" to the role "reboot":

solx# usermod -R reboot baseuser
solx# grep baseuser /etc/user_attr
baseuser::::type=normal;roles=reboot

Create a profile:

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

Connect the profile "REBOOT" to the role "reboot":

solx# rolemod -P REBOOT reboot
solx# grep reboot /etc/user_attr
reboot::::type=role;profiles=REBOOT
baseuser::::type=normal;roles=reboot

So, there is a user called "baseuser" connected to the role "reboot". The role "reboot" has a profile called "REBOOT". All that is left to do is to make sure that the profile (REBOOT) will allow the role (reboot) to execute /usr/sbin/reboot with the correct EUID of 0:

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

Now, the baseuser can log in, su to the role "reboot" and run /usr/sbin/reboot to reboot the machine. Whether in fact you would want to allow anybody to run reboot to reset a machine instead of running shutdown is beyond the scope of this article.

All of this is still based on being somebody as a Unix user. A user that is not connected to a role will not be able to assume that role; a role not connected to a profile will not be able to run that profile; and a profile not connected to the proper execute attribute will not be able to run the command that it has in mind. A lot of files with a lot of colons.

Privileges

Privileges work on a different level -- the process level, which is maintained by the kernel. This is a big difference: RBAC works in userland, related to UIDs and permissions; privileges work on a kernel level; UIDs and file permissions are by-passed. This means that a regular user can, if his process is granted the privilege, read a file that is only readable by root on account of the UID in the file's inode. Or, on the other hand, a user that has read access to a directory may not be able to read anything anymore because the privilege to fork has been revoked from the process privilege list.

To list the total amount of privileges, you can run ppriv:

solx# ppriv -l | wc -l
48

Any of these 48 privileges can be connected to any single process on your system. To make things easier, Sun Microsystems grouped these privileges in the following sets: Effective set, Permitted set, Inheritable set, and Limit set.

• The Effective set is the set of privileges that are currently in effect. It holds the privileges that a process has at runtime. If you must, you can compare it to the Effective UID.
• The Permitted set is the set of privileges a process can maximally obtain. This resembles the Real UID. A privilege can be added to the Effective set only if it is part of the Permitted set.
• The Inheritable set is the set of privileges that will be inherited by, or passed on to, sub-processes. A privilege not in the Inheritable set will neither be in the Effective nor in the Permitted set of a sub-process.
• The Limit set is the set of privileges that a process and its children may obtain. These privileges can be "promoted" to the Permitted set of a process, and from there on upwards, to both the Effective and Inherited sets.

To query the sets and privileges at your disposal, run ppriv again:

solx$ ppriv $$
2141:   -sh
flags = none
        E: basic
        I: basic
        P: basic
        L: all

solx$ ppriv -v $$
2141:   -sh
flags = none
        E: file_link_any,proc_exec,proc_fork,proc_info,proc_session
        I: file_link_any,proc_exec,proc_fork,proc_info,proc_session
        P: file_link_any,proc_exec,proc_fork,proc_info,proc_session
        L: contract_event,contract_observer,cpc_cpu,dtrace_kernel,
(output skipped)

Changing the privileges of processes doesn't seem to be very functional, because when the user exits and logs in again, all changes will be gone. Nevertheless, some examples to get the idea of changing privilege sets.

Here is an example of revoking PRIV_PROC_FORK from the Effective set of PID 1774:

solx# ppriv -s E-proc_fork 1774
solx# ppriv 1774
1774:   -sh
flags = none
        E: basic,!proc_fork
        I: basic
        P: basic
        L: all

In this example, process 1774 will get a permission denied message every time it tries to fork. Try typing ls, for example.

You can allow PID 1882 to read any file on the system by adding PRIV_FILE_DAC_READ to the sets:

solx# ppriv -s EIP+file_dac_read 1882
solx# ppriv 1882
1882:   -sh
flags = none
        E: basic,file_dac_read
        I: basic,file_dac_read
        P: basic,file_dac_read
        L: all

The process with PID 1882 is allowed to read any file on the system, irrespective of the EUID and file permissions.

What we really want is to make these privileges more permanent for particular users of applications. We want these privileges to be set for the user at login time to make sure that every process created by that user will have a desired set of privileges. To achieve that goal, we can add them to /etc/user_attr next to roles entry:

solx# usermod -K defaultpriv=basic,-file_link_any baseuser
solx# grep baseuser /etc/user_attr
baseuser::::type=normal;defaultpriv=basic,-file_link_any;roles=reboot

In this example, user "baseuser" will not be able to create any hardlinks to files that he does not own. The reduced privilege set will be in effect at login time of the user:

solx# su - baseuser
Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
$ln /etc/hosts myhosts
ln: cannot create link myhosts: Not owner

The user can get another confirmation of the lack of a privilege by using the debug option of ppriv:

$ ppriv -eD ln /etc/hosts myhost
ln[9842]: missing privilege "file_link_any"
(output skipped)

So far so good. Apparently RBAC and privileges are two different concepts that work on different levels with "System Security" as a binding factor.

But what about zones? We should talk about the place of zones in all this. Next month, in Part 2 of this article, I will show how to combine privileges and zones to create a secure environment for Apache Web server

[Nov 10, 2006] London OpenSolaris User's Group RBAC Security Overview by Darren Moffat

October 2006 (London) This talk provides an overview of the security features found in the Solaris 10 OS and provides a more in-depth treatment of the Solaris Role-based Access Control (RBAC) facility.

[Dec 22, 2005] Custom Roles Using RBAC in the Solaris OS by Kristopher M. March

July, 2005 In the next example of using RBAC, I am setting up a role to allow the Oracle user to run a script to roll over some web server log files which are generally owned by root. The script, called rollover_logs.sh, is used by DBAs typically during weekend maintenance when the web server software is stopped and started and to clean up space on the disk drives. In preparation, I make sure the script has been tested, remove oracle:dba ownership, and replace with root ownership. Changing ownership prevents the script from being modified to perform other actions. Since this task is often done at obscure times, the DBAs have access to run this at their leisure. I provide the details of this script below.

This example is very similar to the previous role setup except that we use completely different role names and user accounts, and I create a unique profile for each script located in different directories. I use orassist for the role, and then assign that role to the Oracle user account. Oracle_Assistant is the profile name and defines what script will be run by the Oracle user. If there were another script, possibly located in another directory, I would create another profile using Oracle_Assistant as the profile name, and add the location to the new script in the /etc/security/exec_attr file. Specifying multiple tasks or scripts with the same profile name is a standard practice. Just remember to keep them separated by placing each new task on its own line in the exec_attr file.

Rolename: orassist
Username: oracle 

Profile Name: Oracle_Assistant

1. Using a role name of your choice, use roleadd to create the role:

# roleadd -u 2100 -g 10 -d /export/home/orassist -m orassist

Assign a password to the role account.

# passwd orassist 

2. Create a profile to allow the oracle user to run scripts in a specified location.

Edit the /etc/security/prof_attr file and enter the following line:

Oracle_Assistant:::Permit Oracle user to run Oracle scripts:

Save and exit file.

3. The next step is to create the execution attribute entry in the /etc/security/exec_attr. This defines the task or script to be run and the uid the role will assume when running this task. Note that we specify the profile at the start of the line.

Note: There are seven fields to this file with each one separated by a colon; only fields one, two, three, six and seven should be populated at this time.

Insert the execution attributes entry in /etc/security/exec_attr as follows:

Oracle_Assistant:suser:cmd:::<location of script>:uid=0

4. Add the Oracle_Assistant and All [1] profiles to the role as follows:

# rolemod -P Oracle_Assistant,All orassist

5. The rolemod command updates the /etc/user_attr file. Verify that the changes have been made.

# more /etc/user_attr

oracle::::type=normal;roles=orassist
orassist::::type=role;profiles=Oracle_Assistant,All

Here you can see that the orassist role has been assigned to the oracle user account. The Oracle_Assistant profile is now associated with the orassist role.

6. Use the usermod command to assign the role account to the oracle user:

# usermod -R orassist <user_name>  <-- insert oracle here.

With the script owned by root and tested several times, I have peace of mind in turning it over to another user. I'll continue to use RBAC to assist those who have tasks that require superuser privileges. I have included instructions for the user on how to gain access to the role and execute the script.

Instructions for User:

You must be logged in as the required account (in this case, it is oracle). Switch user to the Oracle Assistant role as shown here:

$ su - orassist
Password: <enter password>

Once you are authenticated, the command to run the script is as follows:

$ /<location of script>/rollover_logs.sh

To exit the role and return to original user, type exit.

Disabling Roles

Roles are similar to user accounts. They require a password to be authenticated. The role feature can be disabled easily by manually disabling or locking the role account. One way this is done is by placing an "LK" in the encrypted password field in the /etc/shadow file.

Example:

orassist:LK:12937:7:56:7:::

Script Example (As Described in Scenario Two)

#!/bin/ksh
#   set today's date extension
cleandate=`date '+%c%m%d' | awk '{ print $5 }'`
echo $cleandate
#
#   Roll over logs:  save copy with current date
#                    create new ( empty ) file
#
#
#   rename Apache logs  must be done by root
#
cd <APACHE_HOME>/Apache/Apache/logs
cp access_log access_log.$cleandate
echo > access_log
cp error_log error_log.$cleandate
echo > error_log
cp ssl_request_log ssl_request_log.$cleandate
echo > ssl_request_log

Profiles in the Solaris OS

The next and final section reviews several RBAC profiles that ship with the Solaris OS. You can easily create new roles and add these existing profiles to them to create unique combinations for your users and junior administrators and even backup administrators.

As you were following along with the examples above, you probably noticed the long list of profiles while editing the /etc/prof_attr file. These profiles have been created to aid in system administration functions. By comparing the prof_attr and exec_attr files, you can easily distinguish which profiles are allowed to do what. Knowing this information will allow you to implement these. Most IT data centers employ computer room operators who have the responsibility to monitor activities that take place on numerous servers and mainframes. These folks are often involved in the data backup process. When this becomes true, these folks make good candidates for new roles that allow them to run backup and tape related commands. For example, a system administrator could create a new role called bkadmin and add the Media Backup profile (shown below) which would give bkadmin access to tar files and to mount and unmount tapes.

$ more /etc/security/exec_attr | grep Backup
Media Backup:suser:cmd:::/usr/bin/mt:euid=0
Media Backup:suser:cmd:::/usr/sbin/tar:euid=0
Media Backup:suser:cmd:::/usr/lib/ufs/ufsdump:euid=0;gid=sys

Another helpful set of profiles is the Printer Management profiles. These allow a user access to a large group of printer-related commands used to manage printers and print devices. Creating a role and assigning this group of profiles might help ease the workload of a system administrator.

$ more /etc/security/exec_attr | grep Printer
Printer Management:suser:cmd:::/etc/init.d/lp:euid=0;uid=0
Printer Management:suser:cmd:::/usr/bin/cancel:euid=lp;uid=lp
Printer Management:suser:cmd:::/usr/bin/lpset:egid=14
Printer Management:suser:cmd:::/usr/sbin/accept:euid=lp;uid=lp
Printer Management:suser:cmd:::/usr/lib/lp/local/accept:uid=lp
Printer Management:suser:cmd:::/usr/sbin/lpadmin:egid=14;uid=lp;gid=8
Printer Management:suser:cmd:::/usr/lib/lp/local/lpadmin:uid=lp;gid=8
Printer Management:suser:cmd:::/usr/sbin/lpfilter:euid=lp;uid=lp
Printer Management:suser:cmd:::/usr/sbin/lpforms:euid=lp
Printer Management:suser:cmd:::/usr/sbin/lpmove:euid=lp
Printer Management:suser:cmd:::/usr/sbin/lpshut:euid=lp
Printer Management:suser:cmd:::/usr/sbin/lpusers:euid=lp
Printer Management:suser:cmd:::/usr/bin/lpstat:euid=0
Printer Management:suser:cmd:::/usr/lib/lp/lpsched:uid=0
Printer Management:suser:cmd:::/usr/ucb/lpq:euid=0
Printer Management:suser:cmd:::/usr/ucb/lprm:euid=0

As with most tasks and scripts in UNIX, there is almost always more than one way to accomplish something. This also holds true in the case of creating roles and profiles. If you're familiar with and use the Solaris Management Console (SMC), then you have access to the GUI tool that allows you to review, create, and modify users and roles. There are also several other role management commands that can be utilized to create and manage your roles. The Sun documentation located online has all the additional information needed to use those methods.

[1] A special note about the All (All Rights) profile. The All profile provides a role giving access to all commands not currently assigned to other roles. At the time of role creation, I could have chosen to omit the All profile. This would prevent the role from doing anything else but the assigned role. To give the user some flexibility, I always choose to add it in. Just something to keep in mind as you design your own roles and profiles.

References

Solaris 9 System Administrator Collection, System Administration Guide: Security Services, Chapter 17, Role Based Access Control (Overview)

Solaris 9 System Administrator Collection, System Administration Guide: Security Services, Chapter 18, Role Based Access Control (Tasks)

Solaris 5.8, 5.9 Man pages: useradd, usermod, rolemod

Planet Sun

[Oct 28, 2005] [PDF] The Role of Identity Management in Sarbanes-Oxley Compliance

[Oct 7, 2005] Sun BluePrints OnLine - Archives By Subject

Enforcing the Two-Person Rule Via Role-Based Access Control in the Solaris 10 Operating System (August 2005) by Glenn Brunette

Whether discussing physical or logical access controls, organizations have for years applied the practice of the two-person rule to help secure IT assets. Using the two-person rule is an optional approach for organizations wanting to protect access to key data sets, or to restrict who may perform sensitive or high impact operations on a system. In many circumstances, however, more traditional IT security controls are likely appropriate. Using the two-person rule is most often reserved for restricting the most sensitive IT security operations performed within an organization. Whether and where a given organization could apply the two-person rule depends on its policies, architecture, processes, and requirements.

This Sun BluePrints cookbook describes how to use Solaris Role-Based Access Control (RBAC) in the Solaris 10 Operating System (Solaris OS) to enforce the two-person rule in IT security.

[Apr 5, 2005] Roles and Sarbanes-Oxley -- speculative, but still interesting white paper.

[Mar 30, 2005] [PDF] RBAC in Solaris 10 Sun presentation

[Feb 11, 2005] The Least Privilege Model in the Solaris ...  Privileges and RBAC

The RBAC facility, present in the Solaris OS since version 8, is used to assign specific privileges to roles or users. Solaris RBAC configuration is controlled through four main files, /etc/security/exec_attr, /etc/security/prof_attr, /etc/security/auth_attr, and /etc/user_attr. exec_attr(4) specifies the execution attributes associated with profiles. This generally includes the user and group IDs, commands, and default/limit privileges. prof_attr(4) contains a collection of execution profile names, descriptions, and other attributes. auth_attr(4) contains authorization definitions and descriptions. user_attr(4) contains user and role definitions along with their assigned authorizations, profiles, and projects. For a better understanding of how RBAC operates, read the above-mentioned man pages along with rbac(5), policy.conf(4), chkauthattr(3SECDB) man pages, and the Roles, Rights Profiles, and Privileges section of the Solaris 10 System Administrator Collection.

To allow a group of users to use DTrace, the system administrator would either create a role that had access to the DTrace privileges or assign the privilege directly to a user. The following would create a "debug" role and grant it the appropriate privileges:

roleadd -u 201 -d /export/home/debug -P "Process Management" debug
rolemod -K defaultpriv=basic,dtrace_kernel,dtrace_proc,dtrace_user debug

Now add the necessary users to the debug role with usermod:

usermod -R debug username

The users with the role debug can now use su to access debug, providing the appropriate password, and run the necessary DTrace commands.

Instead of adding roles and making the users access the role via su, the system administrator can also directly assign privileges to a user. The user must be logged out in order for the following command to succeed:

usermod -K defaultpriv=basic,dtrace_kernel,dtrace_proc,dtrace_user username

If additional privileges are required, pinpoint them by running dtrace command ppriv again.

RBAC can also be used in conjunction with the least privilege model to more securely run daemons, like httpd, that need to bind to privileged ports. Many such programs do not actually need root access for anything other than listening on a port below 1024, so granting the role/user that runs the process net_privaddr would remove the need for ever running the process with EUID 0.

[Feb 11, 2005] How To Create Custom Roles Using Based Access Control (RBAC)

How to set up RBAC to allow non-root user to manage in.named on DNS server

The following are assumed:

• The role is: dnsrole
• The user is: dnsadmin
• The profile is: DNS Admin ( case sensitive )
• Home directory for dnsrole is: /export/home/dnsrole
• Home directory for dnsadmin is: /export/home/dnsadmin

Configuration Steps

1. Create the role and assign it a password:

	# roleadd -u 1001 -g 10 -d /export/home/dnsrole -m dnsrole

	# passwd dnsrole

NOTE: Check in /etc/passwd that the shell is /bin/pfsh. This ensures that nobody can log in as the role.

Example line in /etc/passwd:

	dnsrole:x:1001:10::/export/home/dnsrole:/bin/pfsh

2. Create the profile called "DNS Admin":

Edit /etc/security/prof_attr and insert the following line:

	DNS Admin:::BIND Domain Name System administrator: 

3. Add profile to the role using rolemod(1) or by editing /etc/user_attr:

	# rolemod -P "DNS Admin" dnsrole

   Verify that the changes have been made in /etc/user_attr with profiles(1) or grep(1):

	# profiles dnsrole

	DNS Admin

	Basic Solaris User

	All

	# grep dnsrole /etc/user_attr             

	dnsrole::::type=role;profiles=DNS Admin

1. Assign the role 'dnsrole' to the user 'dnsadmin':

1. If 'dnsadmin' already exists then use usermod(1M) to add the role (user must not be  logged in):

      # usermod -R dnsrole dnsadmin

2. Otherwise create new user using useradd(1M) and passwd(1):

      # useradd -u 1002 -g 10 -d /export/home/dnsadmin -m \

      -s /bin/ksh -R dnsrole dnsadmin 

      # passwd dnsadmin

3. Confirm user has been added to role with roles(1) or grep(1):

      # roles dnsadmi

      dnsrole

      # grep ^dnsadmin: /etc/user_attr

      dnsadmin::::type=normal;roles=dnsrole

5. Assign commands to the profile 'dns':

Add the following entries to /etc/security/exec_attr:

	DNS Admin:suser:cmd:BIND 8:BIND 8 DNS:/usr/sbin/in.named:uid=0

	DNS Admin:suser:cmd:ndc:BIND 8 control program:/usr/sbin/ndc:uid=0

   If using Solaris 10 you may need to add a rule for BIND 9:

	DNS Admin:suser:cmd:BIND 9:BIND 9 DNS:/usr/sfw/sbin/named:uid=0

BIND 9 does not use ndc, instead  rndc(1M) is used which does not require RBAC.

6. Create or Modify named configuration files.

To further limit the use of root in configuring and maintaining BIND make dnsadmin the owner of /etc/named.conf and the directory it specifies.

	# chown dnsadmin /etc/named.conf

	# grep -i directory /etc/named.conf

		directory "/var/named/";

	# chown dnsadmin /var/named

7. Test the configuration:

   Login as the user "dnsadmin" and start named:

	$ su dnsrole -c '/usr/sbin/in.named -u dnsadmin'

 To stop named use ndc (for BIND 9 use rndc):

	$ su dnsrole -c '/usr/sbin/ndc stop'

Summary:

In this example the user 'dnsadmin' has been set up to manage the DNS configuration files and assume the role 'dnsrole' to start the named process.

The role 'dnsrole' is only used to start named and to control it with ndc (for BIND 8). 

With this RBAC configuration the DNS process when started by user 'dnsrole' would acquire root privileges and thus have access to its configuration files.

The named options '-u dnsadmin' may be used to specify the user that the server should run as after it initializes.  Furthermore 'dnsadmin' is then permitted to send signals to named as described in the named manual page.

References:

ndc(1M), named(1M), rbac(5), profiles(1), rolemod(1M), roles(1),

rndc(1M), usermod(1M), useradd(1M)

Sys Admin Magazine RBAC as a replacement of sudo

The UNIX administration model of a single, all-powerful superuser is a troublesome limitation in many network computing environments. Sys admins often need to delegate selected administration tasks without granting unrestricted superuser powers. The sudo utility (http://www.courtesan.com/sudo/) is a longtime favorite for fulfilling this function. However, some organizations prohibit the use of “freeware” software tools, especially for such a critical security function. For Solaris sys admins who find themselves in this situation, there is now an alternative.

Role-Based Access Control (RBAC) was introduced in Solaris 8. Adopted from Sun’s Trusted Solaris offering, RBAC has its roots in military and government computing systems where operations are more tightly controlled than in a typical commercial UNIX environment. Like sudo, RBAC allows sys admins the flexibility to grant users superuser privileges on a per-command basis.

To show how RBAC can be used as a substitute for sudo, I will begin with an example sudoers file, then replicate the same configuration using RBAC.

White Papers RBAC in the Solaris Operating Environment.

Also available in PDF (311K) | PS (1.06M)

Role Based Access Control

One of the most challenging problems in managing large networked systems is the complexity of security administration. Today, security administration is costly and prone to error because administrators usually specify access control lists for each user on the system individually. Role based access control (RBAC) is a technology that is attracting increasing attention, particularly for commercial applications, because of its potential for reducing the complexity and cost of security administration in large networked applications.  

With RBAC, security is managed at a level that corresponds closely to the organization's structure. Each user is assigned one or more roles, and each role is assigned one or more privileges that are permitted to users in that role. Security administration with RBAC consists of determining the operations that must be executed by persons in particular jobs, and assigning employees to the proper roles. Complexities introduced by mutually exclusive roles or role hierarchies are handled by the RBAC software, making security administration easier.  

"Sree" <sreep@qnetstaff.com> writes:

>Dear Friends,
>how to provide su access to oracle user and disable direct logging throught
>ssh or telnet. only for user oracle.On Sun systems.

On Solaris systems with RBAC (s8+, I think) you can make the oracle
user into a "role"; that disables direct login access to the account
and also allows you to specify which users can su to it.


see user_attr(4) and rbac(5).

Casper

Recommended Links

---

In case of broken links please try to use Google search. If you find the page please notify us about new location

Solaris[TM] Security Product Index Role Based Access Control (RBAC) -- Sun-maintained list of RBVAC-related links.

System Administration Guide: Security Services

The Least Privilege Model in the Solaris ...(Feb, 2005)  Privileges and RBAC

Instead of adding roles and making the users access the role via su, the system administrator can also directly assign privileges to a user. The user must be logged out in order for the following command to succeed:

usermod -K defaultpriv=basic,dtrace_kernel,dtrace_proc,dtrace_user username

If additional privileges are required, pinpoint them by running dtrace command ppriv again.

RBAC can also be used in conjunction with the least privilege model to more securely run daemons, like httpd, that need to bind to privileged ports. Many such programs do not actually need root access for anything other than listening on a port below 1024, so granting the role/user that runs the process net_privaddr would remove the need for ever running the process with EUID 0.

Integrating the Secure Shell Software (May 2003) by Jason Reid

This article discusses integrating Secure Shell software into an environment. It covers replacing rsh(1) with ssh(1) in scripts, using proxies to bridge disparate networks, limiting privileges with role-based access control (RBAC), and protecting legacy TCP-based applications. This article is the entire fifth chapter of the upcoming Sun BluePrints book "Secure Shell in the Enterprise" by Jason Reid, which will be available in June 2003.

RBAC in the Solaris Operating Environment Whitepaper

Security in the Solaris 9 Operating System Data Sheet

Role Based Access Control and Secure Shell--A Closer Look At Two Solaris Operating Environment Security Features On-Line Blueprints

Sol 9 8/03 System Administration Guide Part II: Managing System Security

Chapter 5 Role-Based Access Control (Overview) Sol 9 8/03 System Administration Guide Part II: Managing System Security  Chapter 6 Role-Based Access Control (Tasks)

Sol 9 8/03 System Administration Guide Part II: Managing System Security Chapter 7 Role-Based Access Control (Reference)

How To Create Custom Roles Using Based Access Control (RBAC)

How to enable/disable root logins via to ssh

How do I restrict access to Apache Web Server in the Solaris[tm] Operating Environment?

The default RBAC Printer Management profile does not work in Solaris [TM] 8

How to start/stop web server (port 80) by a non-root user

Cron jobs fail for Solaris 8 RBAC(Role Based Access Control) roles

Restricting logins to "su" only for a given account

Third-Party Using Solaris™ RBAC Developer Resources (http://developers.sun.com)Authorization Infrastructure in Solaris

Publications

• Conference Papers

  • Framework for Role-Based Delegation Models
    (PDF)

  • Decentralized Group Hierarchies in UNIX: An Experiment and Lessons Learned (PDF, Postscript) ==> see Abstract

  • Group Hierarchies with Decentralized User Assignment in Windows NT (PDF, Postscript) ==> see Abstract

  • NetWare 4 as an Example of RBAC (PDF, Postscript) ==> see Abstract

• Articles

  • Role-Based Access Control (PDF, Postscript)

• Dissertations

Sys Admin Magazine RBAC in the Solaris Operating Environment —http://www.sun.com/software/whitepapers/wp-rbac/

The Solaris Companion: “Role-Based Access Control” by Peter Baer Galvin. Sys Admin, August 2001. — http://www.samag.com/documents/s=1147/sam0108p

[NIST] Role Based Access Control

One of the most challenging problems in managing large networked systems is the complexity of security administration. Today, security administration is costly and prone to error because administrators usually specify access control lists for each user on the system individually. Role based access control (RBAC) is a technology that is attracting increasing attention, particularly for commercial applications, because of its potential for reducing the complexity and cost of security administration in large networked applications. 

With RBAC, security is managed at a level that corresponds closely to the organization's structure. Each user is assigned one or more roles, and each role is assigned one or more privileges that are permitted to users in that role. Security administration with RBAC consists of determining the operations that must be executed by persons in particular jobs, and assigning employees to the proper roles. Complexities introduced by mutually exclusive roles or role hierarchies are handled by the RBAC software, making security administration easier.

Blueprints

Role Based Access Control and Secure Shell--A Closer Look At Two Solaris Operating Environment Security Features (June 2003) by Thomas M. Chalfant

To aid the customer in adopting better security practices, this article introduces and explains two security features in the Solaris operating environment. The first is Role Based Access Control and the second is Secure Shell. The goal is to provide you with enough information to make an effective decision to use or not use these features at your site as well as to address configuration and implementation topics. This article is targeted to the intermediate level of expertise.

Integrating the Secure Shell Software (May 2003) -by Jason Reid  Pages 9-12 are devote to an example of a very restricted role that is able to perform just one external command (scp)

This article discusses integrating Secure Shell software into an environment. It covers replacing rsh(1) with ssh(1) in scripts, using proxies to bridge disparate networks, limiting privileges with role-based access control (RBAC), and protecting legacy TCP-based applications. This article is the entire fifth chapter of the upcoming Sun BluePrints book "Secure Shell in the Enterprise" by Jason Reid, which will be available in June 2003.

Solaris Operating Environment Network Settings for Security: Updated for Solaris 9 Operating Environment (June 2003) by Alex Noordergraaf

This article describes network settings available within the Solaris Operating Environment (Solaris OE) and recommends how to adjust network settings to strengthen the security posture of Solaris OE systems.

This article updates the original article to include changes for Solaris 9 OE. These additions and modifications are incorporated into an updated "nddconfig" script available from http://www.sun.com/blueprints/tools/. This article is ideal for all levels of expertise.

Software White Paper RBAC in the Solaris[tm] Operating Environment

How-to documents

#25968 How To Create Custom Roles Using Based Access Control (RBAC)

Restricting logins to "su" only for a given account

PAM: Making the root user a role

Solaris[TM]: Making the root user a role

Reference

docs.sun.com System Administration Guide, Volume 2

Role-based access control (RBAC) is an alternative to the all-or-nothing security model of traditional superuser-based systems. The problem with the traditional model is not just that superuser is so powerful but that other users are not powerful enough to fix their own problems. Like its predecessor sudo, RBAC provides the ability to package superuser privileges for assignment to user accounts.

With RBAC, you can give users the ability to solve their own problems by assigning them packages of the appropriate privileges. Superuser's capabilities can be diminished by dividing those capabilities into several packages and assigning them separately to individuals sharing administrative responsibilities.

RBAC thus enables separation of powers, controlled delegation of privileged operations to other users, and a variable degree of access control. It includes the following features:

• Authorization - A right that is used to grant access to a restricted function
• Execution profile (or simply profile) - A bundling mechanism for grouping authorizations and commands with special attributes; for example, user and group IDs
• Role - A special type of user account intended for performing a set of administrative tasks

RBAC relies on four databases to provide users access to privileged operations:

• user_attr (extended user attributes database) - Associates users and roles with authorizations and execution profiles
• auth_attr (authorization attributes database) - Defines authorizations and their attributes and identifies the associated help file
• prof_attr (execution profile attributes database) - Defines profiles, lists the profile's assigned authorizations, and identifies the associated help file
• exec_attr (profile execution attributes database) - Defines the privileged operations assigned to a profile

The /etc/user_attr database supplements the passwd and shadow databases. It contains extended user attributes such as authorizations and execution profiles. It also allows roles to be assigned to a user.

A role is a special type of user account that is intended for performing a set of administrative tasks. It is like a normal user account in most respects except that it has a special shell pfksh and users can gain access to it only through the su command; it is not accessible for normal logins. From a role account, a user can access commands with special attributes, typically root user ID, that are not available to users in normal accounts.

The fields in the user_attr database are separated by colons:

                                        user:qualifier:res1:res2:attr

attr is a list of semicolon-separated (;) key-value pairs that describe the security attributes to be applied when the user runs commands. There are four valid keys: auths, profiles, roles, and type.

• auths specifies a comma-separated list of authorization names chosen from names defined in the auth_attr(4) database. Authorization names may include the asterisk (*) character as a wildcard. For example, solaris.device.* means all of the Solaris device authorizations.
• profiles contains an ordered, comma-separated list of profile names chosen from prof_attr(4). A profile determines which commands a user can execute and with which command attributes. At minimum each user in user_attr should have the All profile, which makes all commands available but without any attributes. The order of profiles is important; it works similarly to UNIX search paths. The first profile in the list that contains the command to be executed defines which (if any) attributes are to be applied to the command.
• roles can be assigned to the user using a comma-separated list of role names. Note that roles are defined in the same user_attr database. They are indicated by setting the type value to role. Roles cannot be assigned to other roles.
• type can be set to normal, if this account is for a normal user, or to role, if this account is for a role. A role is assumed by a normal user after the user has logged in.

Authorizations

An authorization is a user right that grants access to a restricted function. It is a unique string that identifies what is being authorized as well as who created the authorization.

Authorizations are checked by certain privileged programs to determine whether users can execute restricted functionality. For example, the solaris.jobs.admin authorization is required for one user to edit another user's crontab file.

All authorizations are stored in the auth_attr database. Authorizations may be assigned directly to users (or roles) in which case they are entered in the user_attr database. Authorizations can also be assigned to execution profiles which in turn are assigned to users.

The fields in the auth_attr database are separated by colons:

Profiles

profname:res1:res2:desc:attr

An optional list of key-value pairs separated by semicolons (;) that describe the security attributes to apply to the object upon execution. Zero or more keys may be specified. There are two valid keys, help and auths.

The keyword help identifies a help file in HTML. Help files can be accessed from the index.html file in the /usr/lib/help/auths/locale/C directory.

auths specifies a comma-separated list of authorization names chosen from those names defined in the auth_attr(4) database. Authorization names may be specified using the asterisk (*) character as a wildcard.

Attributes

An execution attribute associated with a profile is a command (with any special security attributes) that can be run by those users or roles to whom the profile is assigned. Special security attributes refer to such attributes as UID, EUID, GID, EGID that can be added to a process when the command is run.

The definitions of the execution attributes are stored in the exec_attr database.

The fields in the exec_attr database are separated by colons:

name:policy:type:res1:res2:id:attr

The type of entity whose attributes are specified. Currently, the only valid type is cmd (command).

attr An optional list of semicolon (;) separated key-value pairs that describe the security attributes to apply to the entity upon execution. Zero or more keys may be specified. The list of valid key words depends on the policy being enforced. There are four valid keys: euid, uid, egid, and gid.

euid and uid contain a single user name or a numeric user ID. Commands designated with euid run with the effective UID indicated, which is similar to setting the setuid bit on an executable file. Commands designated with uid run with both the real and effective UIDs.

egid and gid contain a single group name or numeric group ID. Commands designated with egid run with the effective GID indicated, which is similar to setting the setgid bit on an executable file. Commands designated with gid run with both the real and effective GIDs.

How to assume role:

To assume a role, use the su command. You cannot log in to a role. For example:

%su my-role Password: my-role-password #

Command	Description
auths(1)	Display authorizations for a user.
makedbm(1M)	Make a dbm file.
nscd(1M)	Name service cache daemon, useful for caching the user_attr, prof_attr, and exec_attr databases.
pam_roles(5)	Role account management module for PAM. Checks for the authorization to assume role.
pfexec(1)	Profile shells, used by profile shells to execute commands with attributes specified in the exec_attr database.
policy.conf(4)	Configuration file for security policy. Lists granted authorizations.
profiles(1)	Display profiles for a specified user.
roles(1)	Display roles granted to a user.
roleadd(1M)	Add a role account on the system.
roledel(1M)	Delete a role's account from the system.
rolemod(1M)	Modify a role's account information on the system.
useradd(1M)	Add a user account on the system. The -P option assigns a role to a user's account.
userdel(1M)	Delete a user's login from the system.
usermod(1M)	Modify a user's account information on the system.

Etc

RBAC Principles Disclaimer & Definitions

This document is merely a re-sorting of the “Principles” output from the NAC 2001 Fall conference, which will hopefully act as a starting point to more comprehensive documentation.  The conference material did not contain all of the “principles” that may apply to RBAC, but there were also some good ideas expressed in the contents that were not “principles” as well.  This document re-sorts the conference document into “RBAC Principles” items and “Role Engineering Best Practices” items for further discussion.

Definitions:
Principle: A “principle”, as used in this context, is a constant (some might call a “rule”) that defines a particular behavior or characteristic that any RBAC system must include, exhibit or comply with.

 Best Practice: A “best practice” can be an insight based on experience, a recommendation based on research, or even an opinion based on sound reasoning.  In this case, certain “best practices” for role engineering or role discovery were contained within the NAC conference “Principle” document.

Principles:
1.      The RBAC system must delineate users, roles, and permissions.

2.      A user can be assigned to multiple roles.

3.      The system must support the notion of “Separation of Duty “ constraints.

4.      Must leverage existing standards to the extent possible.

5.      An inheritance model must be supported so that a role can inherit rights other roles .

6.      The permission with the least privilege applies, in cases where a user is assigned to multiple roles, and two or more roles define a permission on the same object.

7.      The system must log changes to role assignments.

8.      The system must provide an aggregated view of all permissions assigned to a particular user.

9.      The system must provide a view of all users assigned to a particular permission.

110.     There must be an administrative interface to add/change/delete roles, permissions and users – as well as the assignments of permissions to roles and roles to users.

111.     A role should be able to map to one or more “groups” on one or more target systems.

112.     ”Users” can be people, applications, devices or functions.
 

Best Practices for Role Engineering:

1.      Roles are abstractions of system entitlements that consider two design criteria:

• Consolidation of entities into meaningful groups that facilitate ease of administration.
• Collections of permissions that are meaningful to specific user communities

2.      There are three basic approaches to role engineering:

• “Bottom Up”: which derives roles from the groups and permissions defined on the existing systems and platforms in the enterprise.
• “Top Down”: which derives roles from an analysis of business function and organizational criteria, typically from a “zero base” starting point.
• “Hybrid”: which, as the name implies, derives roles using a combination of bottom up and top down approaches.

3.      The top down approach typically is much more difficult to implement, because it will probably result in significant changes to legacy group and permission models.

4.      The bottom up approach is typically easier to implement, because the RBAC system will overlay the legacy group and permission models.

5.      A successful role definition approach will likely be a hybrid approach

6.      The objective of role modeling is to maximize flexibility with minimal administrative effort.

7.      Role engineering should consider how role and user administration is to be delegated.  More decentralized models benefit from more top down analysis.

8.      Top down role engineering will aggregate business processes into organizational parameters.

9.      A top down approach can only be successful with participation and buy-in from business units.

110.     A role typically maps to a group on a legacy system.

111.     Successful implementation of RBAC benefits from a cultural commitment to define common roles that supercede individual privileges.

112.     Roles do not have meaning unless they are used to define access privileges.

113.     Plan for role life cycle management

114.     Consider using use case modeling to validate role definitions.

Access Control Model

• Ravi Sandhu's RBAC Research Group
• NIST's  RBAC Research
• OASIS

Pervasive Computing

• Gaia Project
• Mobile and Ubiquitous Computing Reading List

Security Research Links

• Matt Blaze's  cryptography resource on the Web
• Agile Management of Dynamic Collaboration
• Distributed Security Research Group
• "IETF's Internet Security Glossary (rfc 2828)" 
• Wireless Network Security
• UC Davis Security Research Laboratory
• Kerberos

Security-related conferences (great places to pick papers)

• http://www.acm.org/sigsac/ccs.html
• http://www.ieee-security.org/TC/SP-Index.html
• http://www.usenix.org/events/bytopic/security.html
• http://www.csl.sri.com/programs/security/csfw/
• http://www.acm.org/sigsac/sacmat.html
• http://www.isoc.org/isoc/conferences/ndss/
• http://www.acm.org/sigsac/nspw.html
• http://www.acsac.org/
• http://www.icis2002.org/main.htm
• http://www.iacr.org/
• http://www.acm.org/sigcomm/
• http://www.acm.org/sigmobile/confs/mobicom.html

Places of interest on the web

• Computer Security History Project at UC Davis Security Laboratory has copies of old but seminal papers.
• Professor Ronald L. Rivest's Cryptography and Security page
• Applied Security Reading Group at MIT 
• Berkeley Crypto Reading Group at UC Berkeley
• Security Reading Group at UIUC