Solaris 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.

Solaris RBAC as implemented in Solaris 10 was an innovative (may be even revolutionary) feature  that is twenty years ahead of its time. And as happens with really innovative features it was happily ignored outside the US government for all those years since Solaris 10 was launched.  It solves the same access control problem as  sudo (another innovative and underutilized program) is trying to solve too, but in more elegant and constructive way.

RBAC in Solaris 10 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 first 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 fall short of requirements of enterprise system administrators and only Solaris 10 implementation has the qualities necessary for enterprise adoption of this feature.  But again as it is often happens with innovative solutions it was ignored by industry.  Even in department of the US government were its usage it mandatory it is vastly underutilized.

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 This is a 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 strong 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 sets of the appropriate privileges. This way the need (and the number of users) who have the ability to became root can be diminished by assigning such sets 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.

NEWS CONTENTS

• 20061210 : Sys Admin System Security in SolarisTM 10 Privileges and Zones in Perspective -- Part 1 by Peter van der Weerd ( Sys Admin System Security in SolarisTM 10 Privileges and Zones in Perspective -- Part 1, Dec 10, 2006 )
• 20061110 : London OpenSolaris Users Group RBAC Security Overview by Darren Moffat ( London OpenSolaris User's Group RBAC Security Overview, Nov 10, 2006 )
• 20051222 : Custom Roles Using RBAC in the Solaris OS by Kristopher M. March ( Custom Roles Using RBAC in the Solaris OS, Dec 22, 2005 )
• 20051028 : The Role of Identity Management in Sarbanes-Oxley Compliance ( The Role of Identity Management in Sarbanes-Oxley Compliance, Oct 28, 2005 )
• 20051007 : Sun BluePrints OnLine - Archives By Subject ( Sun BluePrints OnLine - Archives By Subject, Oct 7, 2005 )
• 20050405 : Roles and Sarbanes-Oxley ( Roles and Sarbanes-Oxley, Apr 5, 2005 )
• 20050330 : RBAC in Solaris 10 ( RBAC in Solaris 10, Mar 30, 2005 )
• 20050211 : The Least Privilege Model in the Solaris ... ( The Least Privilege Model in the Solaris ..., Feb 11, 2005 )
• 20050211 : How To Create Custom Roles Using Based Access Control (RBAC) ( How To Create Custom Roles Using Based Access Control (RBAC) , Feb 11, 2005 )
• 20050211 : How to set up RBAC to allow non-root user to manage in.named on DNS server ( How to set up RBAC to allow non-root user to manage in.named on DNS server, )
• 20050211 : Sys Admin Magazine ( Sys Admin Magazine, )
• 20050211 : White Papers ( White Papers, )
• 20050211 : su - access to oracle account by Casper H.S. Dik ( su - access to oracle account, )
• 200229 : RBAC on Solaris: emulation of SUDO ( RBAC on Solaris: emulation of SUDO, )

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

[Oct 28, 2005] 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] RBAC in Solaris 10

Sun presentation [PDF]

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

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)

by Alan Orndorff
Operating System: Solaris 8

UNIX has always allowed users to be granted access privileges for running programs that they normally don't have access to. Even with modern-day Solaris, you still have the ability to set your user id and group id, as well as access control lists, and you can still use the venerable third-party sudo program.

Things have changed just a tad with Solaris 8, though. We now have a process known as Role-based Access Control (RBAC). Although sudo is a bit easier to set up, with RBAC you no longer need to compile another program to provide this functionality.

Foundation

There are essentially two directories and four files that are used to configure RBAC. The file in the /etc directory is user_attr. The files in the /etc/security directory are auth_attr, prof_attr and exec_attr.

The /etc/user_attr file is an extension to /etc/passwd and /etc/shadow. When you create a role, it's stored in this file.

A role is similar to a typical user account, except you can't log on to the system with a role user account. You log on as a normal user and then su to the role. The role determines which commands your users have access to outside of the normal user commands.

The /etc/security/auth_attr file is used to grant access to normal system-type commands, such as changing the date and time or Printer Management. When defining a custom role, you may or may not need to update this file.

The /etc/security/prof_attr file contains execution profiles. A tag in this file matches tags in the exec_attr file.

The /etc/security/exec_attr file is where the actual commands that the user can run are stored. This is the key to the whole system.

All of these files use the following delimiters:

• Colon. Used as a field separator within the file. For example, you could have a line that looks as follows:

  Fruit: Vegetables: Meats: Breads
  

• Semicolon. Used to separate key value pairs within the file. We could separate apples and lemons like so:

  apples=red; lemons=yellow
  

• Comma. Used to separate an ordered list within the file:

  lions, tigers, bears
  

• Period. Used to separate the prefix from the suffix. This separation defines execution profiles with finer granularity:

  	solaris.system.date
  	solaris.system.shutdown
  

To create a role-based access control, you add the role to user_attr and then create the entries in prof_attr and exec_attr. You can use the built-in authority schemes as defined in the auth_attr file, or you can add your own to this file as well.

The four files

It's important to understand these files and how they relate to each other. To help you understand them, we'll now describe the use of each file in detail.

/etc/user_attr

The first file we'll examine is /etc/user_attr. The Extender User Attributes (/etc/user_attr) file is an extension to your normal /etc/passwd and /etc/shadow files. This file allows you to assign roles to users, specify which account you'll use to run certain commands, and assign users to profiles and authorizations.

The role account also has special shells associated with it. Instead of assigning the typical shells such as bourne, csh, ksh, etc., you select one of the three profile shells:

• pfsh. Profile bourne shell.
• pfcsh. Profile C shell.
• pfksh. Profile Korn shell.

If the user decides to change the shell to any shell other than these, then the role commands will not work. You must be in one of these special shells to execute the role commands.

The /etc/user_attr file has the following fields:

• User. The name of the user or role as it appears in /etc/passwd.
• Qualifier. Reserved for future use.
• Res1. Reserved for future use.
• Res2. Reserved for future use.
• Attr. An optional list that describes the security attributes to be applied when the user runs the commands. There are four valid keys:
  
  • Auths. Specifies a name chosen from the names defined in /etc/security/auth_attr. These names can contain wildcards.
  • Profiles. Specifies a name chosen from the profile names specified in /etc/security/prof_attr. A profile determines which commands a user can execute. There are some severe security implications for Profiles that we'll discuss later.
  • Roles. Defines each role needed. They are defined in this same file. Roles are defined by setting the type to role. You can't assign roles to other roles.
  • Type. Indicates what kind of account it is. Type can be set to "normal," which indicates that it's a normal user, or to "role" if the account is for a role.

These are all of the possible elements the user_attr file can contain. The following is an example:

root::::type=normal;auths=solaris.*, \
solaris.grant;profiles=All

The first field specifies root. We know that it's a user account, as the type is set to "normal." The root user account is authorized to use the solaris.* and solaris.grant authorizations as defined in auth_attr, and can utilize commands that are defined for the "All" profile.

An example of a role entry would look like this:

filemngr::::type=role;profile=Filesystem
⇒Management,All

The name of the role is filemngr, as indicated by the type=role tag, and the role has access to the commands that are allowed by the "Filesystem Management" profile and the "All" profiles.

/etc/security/auth_attr

The second file we'll look at is /etc/security/aut_attr. This file contains authorizations to restricted system functions. Some of these functions include changing date/time, system shutdown, auditing, and other system-type functions. You can create your own system definitions and include them in this file as well. Any function that starts with "solaris.something" is defined by Sun. If you want to add your own authorizations, we recommend that you use your company Web address in reverse format (i.e., com.yourcompany.authorization_name). By doing this, you'll ensure that future upgrades or changes in future versions of Solaris won't wipe out your custom definitions.

You can add authorizations for users or roles in one of two ways. You can either add authorizations directly in the /etc/user_attr file, or indirectly by adding them to profiles and then assigning the profile to a user or role.

Certain privileged programs use this file to determine the users' rights to execute that program. This file also defines the location of the Help file to use in GUI programs. The file has the following fields:

• Authname. A unique string used to define the authorization in the format of prefix.suffix. The prefix should be your company's domain name in reverse syntax, and the suffix should be the functional area that you're granting authorizations for. This might look like com.yourcompanyname.authname. If the authname ends in a period, then it doesn't grant or deny access to programs, but can be used within a GUI application as a heading.
• Res1. Reserved for future use.
• Res2. Reserved for future use.
• Short-desc. A short description suitable for displaying in a GUI.
• Long-desc. A long description that could be used in a GUI Help file.
• Attr. An optional list that describes the attributes of the authorization. The Help keyword identifies a Help file in HTML format. You can access help files from the index.html file in the /usr/lib/help/auths/locale/C directory.

Some example entries in this file would look like:

solaris.jobs.:::Cron and At Jobs::
⇒help=JobHeader.html
solaris.jobs.admin:::Cron & At 
⇒Adminis-trator::help=JobsAdmin.html
solaris.jobs.grant:::Delegate Cron & 
⇒At Administration::help=JobsGrant.html

The first entry ends in a period, so its use is limited to a heading in a GUI application. The second entry allows a user to view or change cron or at jobs on the local machine. The third entry is also a special type. Whenever an authorization ends in .grant, it allows the user to grant authorizations to other uses. Be careful of using .grant, as whichever user you give this right to could arbitrarily let other users use these commands as well.

/etc/security/prof_attr

An execution profile is a way of bundling together all the authorizations and commands that you then assign to users and roles.

The file has the following fields:

• Profname. The case-sensitive name of the profile.
• Res1. Reserved for future use.
• Res2. Reserved for future use.
• Desc. This field should explain why the role exists and why you would let a user run these commands. It should be suitable for use as a Help file for a GUI application.
• Attr. An optional list that describes the authorizations or Help files to be used by the command upon execution. The Help file has the same specifications as described for the auth_attr file. The auths keyword corresponds to authorizations created in the auth_attr file. You can specify wildcards here.

A couple of example entries from this file include the following:

Audit Control:::Administer the audit 
⇒subsystem:auths=solaris.audit.config,
⇒solaris.jobs.admin;help=AuditControl.html

Device Management:::Control Access to 
⇒Remov-able Me-dia:auths=solaris.device.*;
⇒help=DevMgmt.html

The first example shows that the profile name is "Audit Control." This profile is authorized to run all commands associated with solaris.audit.config in the auth_attr file. The Help file is /usr/lib/help/auths/locale/C/AuditControl.html. The second example shows the use of a wildcard allowing the user to run all commands associated with the solaris.device authorizations as defined in auth_attr.

/etc/security/exec_attr

This file is the key to the whole system. In it, we define exactly which commands the user can run. After you define a policy, you need to edit this file and define which commands that profile is allowed to run, as well as how you want that command to run. In /etc/security/exec_attr, you can tell the system to run the command as user id, effective user id, group id, or effective group id. The file has the following fields:

• Name. The name of the profile. This matches the entry in prof_attr.
• Policy. The security policy associated with the execution profile. Currently there's only one: suser.
• Type. Currently the only valid type is cmd (command).
• Res1. Reserved for future use.
• Res2. Reserved for future use.
• Id. The full path to and the name of the command that the user is allowed to run. You can use wildcards here. If you need to use command line switches, then you'll need to write a script and point the id to the full path name of the script.
• Attr. An optional list containing one or more of the following followed by a value: uid, euid, gid or guid. The value or name of the user id, effective user id, group id, or effective user id is the same as defined in /etc/passwd or /etc/group.

A few example entries from this file include:

All:suser:cmd:::*:
Audit Control:suser:cmd:::
⇒/etc/init.d/audit:euid=0;egid=3
Audit Control:suser:cmd:::
⇒/etc/security/bsmconv:uid=0
Audit Control:suser:cmd:::
⇒/etc/security/bsmunconv:uid=0
Audit Control:suser:cmd:::
⇒/usr/sbin/audit:euid=0

The first entry here is of some importance. The "All" profile lets the user run any command on the system without any special privileges. Not granting a user access to the "All" profile takes away this access. The only commands that the user can now run are those that the remaining profiles grant him access to run. By not granting access to the "All" profile, you can severely restrict the commands that the user is allowed to run, even down to just one command.

The rest of the examples show you that the profile "Audit Control" can be set up to run a few different commands in different directories. Also, you can see that some of these commands run as uid=0 or euid=0, and the first command will also run with an egid equal to 3. Make sure that these match up with the permissions of the command on the file system.

Logins and su

In order for the typical user to use these commands, he must log on as himself and then su to the role account. No one is allowed to log on with a role account. A role is created in the same fashion as a user. It has all the attributes that a normal user account has. If you decide that you want to temporarily suspend a role, simply change the password on the role account and don't give anyone the new password. When you're ready to resume the role, either reset the password to what it was or assign a new one and let the users know what it is.

Role commands

The following commands are used to create and manage roles: roleadd, rolemod, roledel, /etc/init.d/nscd, profiles, roles, useradd, userdel, usermod and vi. Note that admintool isn't listed.

To create a role, use the following roleadd command:

roleadd -c comment -d home dir -e 
⇒expire -f inactive -g group -G group 
⇒-m -u uid -s shell -A  authorization 
⇒-P profile role

Those familiar with useradd will have no problem with this command. The -m creates the home dir if it doesn't already exist. Make sure that you remember to use pfsh, pfksh or pfcsh for the shell. Before assigning an authorization or profile, they must exist in auth_attr or prof_attr, respectively, before issuing the command. The role account has the same restrictions as a user account in terms of length and other attributes.

To modify a role, you use the rolemod command. This command is analogous to the usermod command, and follows the same format:

rolemod -u uid -g group -G group -d 
⇒dir -m -s shell -c comment -l new_name 
⇒-f inactive -e expire -A authorization 
⇒-P profile  role

Finally, to remove a role, use the roledel command as follows:

roledel -r  role

As with userdel, the -r removes the home directory.

If you want to see a list of profiles that you currently belong to, use the profiles command:

profiles -l user

Using the -l switch allows you to see which commands are associated with the profile, as well as the special attributes, such as eid or gid, of the command. If you want to see the profiles assigned to a particular user, then specify the user's name as part of the command.

If you want to see what roles are assigned to your user account, you can use the roles command as follows:

roles user

The useradd and usermod commands have been updated with additional switches. This includes the -A and -P options, respectively, which assign authorizations and profiles to the user. They have also added the -R option to assign roles to a user.

Example

One of the more useful commands for helping to debug network-related problems is the snoop command. Because this command can be used to read passwords, normal users usually don't have access to this command. The following is an example of how to give users access to the snoop command. Remember that this is just an example, and you probably will not want to do this in the real world.

Add the following to the end of the /etc/security/exec_attr file:

Snoop:suser:cmd:::/usr/sbin/snoop:uid=0

Now, update the /etc/security/prof_attr file as follows:

Snoop:::Allow users to run the snoop command:

Once this is complete, create the following role:

roleadd -m -d /export/home/snoop -c 
⇒"Allow users to run snoop" -s 
⇒/usr/bin/pfsh -P Snoop,All usrsnoop

Then you can set the password for the usrsnoop account:

passwd usrsnoop

Now, grant the appropriate user accounts the right to use the command:

usermod -R usrsnoop user

You're now ready to test your setup. Do this with the following commands:

su - user
su role (usrsnoop)
run role commands (/usr/sbin/snoop)

Inform the end users of the (role) snoopusr account, the password, and what it's used for.

Name Server Cache Daemon

Sometimes when you add or modify a role/profile, the role/profile won't take effect right away. The reason that it may not take effect immediately could be the name server cache daemon. If you make changes and they aren't showing up, you may need to stop and then restart this daemon. To do this, issue the following commands:

/etc/init.d/nscd stop
/etc/init.d/nscd start

You can also try adjusting your nscd settings by modifying /ect/nscd.conf.

Conclusion

Like anything new, getting used to RBAC can take a little time, but in the long run it will solve problems that are not easily solved by setting UNIX permissions. It also can augment or replace sudo if you're currently using that solution.

su - access to oracle account by Casper H.S. Dik

Newsgroups: comp.security.unix

Date: 2002-08-28 08:00:22 PST

"Sree" <[email protected]> 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

RBAC on Solaris: emulation of SUDO

Role-based access control allows system administrators to delegate the administrative control of parts of the system to users. Users can be given the ability to run commands with additional privilege in two ways. Either by assigning a profile directly to the user, in which case no additional authentication is required. Or by creating a role. It can also be used to build restrictive environments for users by removing their ability to run commands they would normally be allowed to.

OpenSolaris UserGroup RBAC presenation

Why use RBAC vs sudo (for Solaris)

(Note this may not apply to all OpenSolaris distributions)

• RBAC is built into Solaris (since S8) and supported by Sun.
• RBAC is documented, patched, updated and integrated throughout Solaris
• RBAC is supported by the Solaris Management Console and WebMin GUI's
• RBAC is integrated with SMF in Solaris 10.
• RBAC is evaluated along with the rest of the OS during Common Criteria evaluations. Sudo is not included in the evaluation.
• RBAC actions are audited by the same CC evaluated audit facility used through Solaris
• RBAC offers roles as well as the pfexec command which provides a similar capability to sudo.

Why use sudo rather than RBAC

• Cross platform
• Support for control of CLI arguments (see TODO list below)
• Support for setting per command environment (see TODO list below)

What about sudo & privileges ?

Having sudo be privilege aware would be great for OpenSolaris as well. This would probably be done by adding new keywords to the sudoers grammar so that you can specify the privileges that the command should run with. It would be very cool if someone could implement this and contribute it back to the main sudo branch.

RBAC Best Practices for OpenSolaris developers

The following best practice documents for using RBAC in developing other parts of OpenSolaris can be found in the ARC community:

• When to use setuid vs RBAC roles

• Adding New authorisations to OpenSolaris

• Bulding RBAC Rights Profiles

RBAC TODO List

The following is a list of mini projects or RFEs that we know we need to implement in the OpenSolaris RBAC framework to get parity with sudo or to fill a customer need.

Please help us out by implementing one of these:

• Control of environment variables: 6227888

Ability to set and clear any environment variable for a specific entry in exec_attr(4).

• Control of command line args: 5097247

Restrict which arguments to a command get the additional privilege, For example run passwd(1) but only with a user name not with any of the password aging options.

• Netgroups integration 4986798

For all of the RBAC databases that make up a profile definition and assignment of it to a user (execattr, profattr, userattr) control which hosts it is valid on using netgroups. The currently unused "qualifier" field in userattr(4) is intended for this as is one of the reserved fields in prof_attr(4).

History of RBAC in Solaris

The main stream Solaris first got RBAC in Solaris 8. In Solaris 9 new profiles were added but no new core functionality from the framework. In Solaris 10 RBAC was integrated with least privilege, SMF and SMC.

Trusted Solaris (now replaced by Trusted Extensions) had an RBAC system in all of its releases going back to the SunOS 4.1.3 based versions. The implementation was slightly different but the basic concepts are the same.

Recommended Links

Softpanorama Recommended

Top articles

Sites

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

Random Findings

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

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019