RBAC in Solaris
The following figure illustrates how the RBAC databases work together.
In case of Solaris the user_attr,prof_attr,auth_attr,policy.c work together to make the RBAC work.
Figure 7–1 RBAC Database Relations
The user_attr database
stores the basic definitions for both users and roles, which are differentiated by the type field. The user_attrdatabase contains the attributes that are shown in the figure, which includes a comma-separated list of rights profile names.
The user_attr is responsile for assigning the profiles,authorizations to the roles or users.
The prof_attr database
contains rights profile identification information, authorizations that are assigned to the profile, and supplementary profiles.
The exec_attr database
identifies the security policy and contains commands with their associated security attributes. The auth_attr database supplies authorization information to the Sun Management Console tools.This is responsible for restricting users to run only certain commands.This defines the profiles to the commands which can be run by them.
The auth_attr database
defines the authorizations which can be given to users or roles in the user_attr database or the prof_attr database.
The policy.conf data base:
supplies default authorizations and rights profiles that are to be applied to all users.
The user_attr DatabaseThe
user_attr database contains user and role information that supplements the
passwd and
shadow databases. The
user_attrdatabase contains extended user attributes such as authorizations, rights profiles, and assigned roles. The fields in the
user_attrdatabase are separated by colons, as follows:
user:qualifier:res1:res2:attr |
The following table describes these fields.
Field Name | Description |
|---|
user | The name of the user or role as specified in the passwd database. |
qualifier | Reserved for future use. |
res1 | Reserved for future use. |
res2 | Reserved for future use. |
attr | An optional list of semicolon-separated (;) key-value pairs that describes the security attributes to be applied when the user runs commands. The four valid keys are type, auths, profiles, and roles.
The type key can be set to normal, if this account is for a normal user, or to role, if this account is for a role. The auths key specifies a comma-separated list of authorization names that are chosen from names that are defined in the auth_attr database. Authorization names can include the asterisk (*) character as a wildcard. For example, solaris.device.* means all of the Solaris device authorizations. The profiles key specifies an ordered, comma-separated list of rights profile names from the prof_attrdatabase. The order of rights profiles works similarly to UNIX search paths. The first rights profile in the list that contains the command to be executed defines which (if any) attributes are to be applied to the command. The roles key can be assigned to the user through a comma-separated list of role names. Note that roles are defined in the same user_attr database. Roles are indicated by setting the type value to role. Roles cannot be assigned to other roles.
|
The following example demonstrates how the Operator role is defined in a typical user_attr database and how it is assigned to userjohnDoe. Roles and users are differentiated by the type keyword.
% grep operator /etc/user_attr
johnDoe::::type=normal;roles=sysadmin,operator
operator::::profiles=Operator;type=role |
The auth_attr Database
All authorizations are stored in the
auth_attr database. Authorizations can be assigned directly to users (or roles) in the
user_attrdatabase. Authorizations can also be assigned to rights profiles, which are assigned to users.
The fields in the auth_attr database are separated by colons, as follows:
authname:res1:res2:short_desc:long_desc:attr |
The following table describes these fields.
Field Name | Description |
|---|
authname | A unique character string that is used to identify the authorization in the format prefix.[suffix]. Authorizations for the Solaris operating environment use solaris as a prefix. All other authorizations should use a prefix that begins with the reverse-order Internet domain name of the organization that creates the authorization (for example, com.xyzcompany). The suffix indicates what is being authorized, which is typically the functional area and operation. When the authname consists of a prefix and functional area and ends with a period, the authname serves as a heading to be used by applications in their GUIs, rather than as an actual authorization. The authname ofsolaris.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 authorizations with the same prefix and functional area to other users. The authname ofsolaris.printmgr.grant is an example of a grant authorization. solaris.printmgr.grant gives the user the right to delegate such authorizations as solaris.printmgr.admin and solaris.printmgr.nobanner to other users. |
res1 | Reserved for future use. |
res2 | Reserved for future use. |
short_desc | A terse name for the authorization that is suitable for display in user interfaces, such as in a scrolling list in a GUI. |
long_desc | A long description. This field identifies the purpose of the authorization, the applications in which it is used, and the type of user who might be interested in using it. The long description can be displayed in the help text of an application. |
attr | An optional list of semicolon-separated (;) key-value pairs that describe the attributes of an authorization. Zero or more keys can be specified. 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. |
The following example shows an auth_attr database with some typical values.
% grep printer /etc/security/auth_attr
solaris.admin.printer.:::Printer Information::help=AuthPrinterHeader.html
solaris.admin.printer.delete:::Delete Printer Information::help=AuthPrinterDelete.html
solaris.admin.printer.modify:::Update Printer Information::help=AuthPrinterModify.html
solaris.admin.printer.read:::View Printer Information::help=AuthPrinterRead.html |
Note that solaris.admin.printer. is defined to be a heading, because it ends in a dot (.). Headings are used by the GUIs to organize families of authorizations.
The prof_attr Database
The
prof_attr database stores the name, description, help file location, and authorizations that are assigned to rights profiles. The commands and security attributes that are assigned to rights profiles are stored in the
exec_attr database (see
The exec_attrDatabase). The fields in the
prof_attr database are separated by colons:
profname:res1:res2:desc:attr |
The following table describes these fields.
Field Name | Description |
|---|
profname | The name of the rights profile. Rights profile names are case-sensitive. This name is also used by the user_attrdatabase to indicate rights profiles that are assigned to roles and users. |
res1 | Reserved for future use. |
res2 | Reserved for future use. |
desc | A long description. This field should explain the purpose of the rights profile, including what type of user would be interested in using it. The long description should be suitable for display in the help text of an application. |
attr | An optional list of key-value pairs that are separated by semicolons (;) that describes the security attributes to apply to the object on execution. Zero or more keys can be specified. The two valid keys are 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. The keyword auths specifies a comma-separated list of authorization names that are chosen from those names that are defined in the auth_attr database. Authorization names can be specified with the asterisk (*) character as a wildcard. |
The following example shows a typical prof_attr database. Note that the Printer Management rights profile is a supplementary rights profile that is assigned to the Operator rights profile.
% grep 'Printer Management' /etc/security/prof_attr
Printer Management:::Manage printers, daemons, spooling:help=RtPrntAdmin.html; \
auths=solaris.admin.printer.read,solaris.admin.printer.modify,solaris.admin.printer.delete \
Operator:::Can perform simple administrative tasks:profiles=Printer Management,\
Media Backup,All;help=RtOperator.html
... |
The exec_attr Database
An execution attribute is a command that is associated with a specific UID or GID and that is assigned to a rights profile. The command with its security attributes can be run by users or roles to whom the rights profile is assigned.
The exec_attr database stores the definitions of the execution attributes.
The fields in the exec_attr database are separated by colons:
name:policy:type:res1:res2:id:attr |
The following table describes these fields.
Field Name | Description |
|---|
name | The name of the rights profile. Rights profile names are case-sensitive. The name refers to a rights profile in theprof_attr database. |
policy | The security policy that is associated with this entry. Currently, suser (the superuser policy model) is the only valid entry. |
type | The type of entity that is specified. Currently, the only valid entity type is cmd (command). |
res1 | Reserved for future use. |
res2 | Reserved for future use. |
id | A string that identifies the entity. 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 semicolon (;) separated key-value pairs that describes the security attributes to apply to the entity on execution. Zero or more keys can be specified. The list of valid keywords depends on the policy that is enforced. The four valid keys are euid, uid, egid, and gid. The euid and uid keywords contain a single user name or a numeric user ID (UID). Commands that are designated witheuid run with the effective UID indicated, which is similar to setting the setuid bit on an executable file. Commands that are designated with uid run with both the real and effective UIDs. The egid and gid keywords contain a single group name or numeric group ID (GID). Commands that are designated with egid run with the effective GID indicated, which is similar to setting the setgid bit on an executable file. Commands that are designated with gid run with both the real and effective GIDs. |
The following example shows some typical values from an exec_attr database.
% grep 'Printer Management' /etc/security/exec_attr
Printer Management:suser:cmd:::/usr/sbin/accept:euid=lp
Printer Management:suser:cmd:::/usr/ucb/lpq:euid=0
Printer Management:suser:cmd:::/etc/init.d/lp:euid=0
.
.
. |
The policy.conf File
The
policy.conf file provides a way of granting specific rights profiles and authorizations to all users. The two types of entries in the file consist of key-value pairs. They are the following:
The following example shows some typical values from a policy.conf database.
# grep AUTHS /etc/security/policy
AUTHS_GRANTED=solaris.device.cdrw
# grep PROFS /etc/security/policy
PROFS_GRANTED=Basic Solaris User |
This was referred from:http://download.oracle.com/docs/cd/E19683-01/817-0365/6mg5vpmek/index.html
RBAC in LINUX
In case of Linux all these are taken care by a single file /etc/sudoers
To my understanding there is no right profile concept in Linux.It's all taken care
by grouping users.
CMD_ALIAS takes care of the work done by user_attr in Solaris.In Linux CMD_ALIAS is used to group commands whereas in Solaris user_attr is used to define commands to a particular profile.
For example:
# All the shutdown commands
Cmnd_Alias SHUTDOWN_CMDS = /sbin/shutdown, /sbin/reboot, /sbin/halt
# Printing commands
Cmnd_Alias PRINTING_CMDS = /usr/sbin/lpc, /usr/sbin/lprm
# Admin commands
Cmnd_Alias ADMIN_CMDS = /usr/sbin/passwd, /usr/sbin/useradd, /usr/sbin/userdel, /usr/sbin/usermod, /usr/sbin/visudo
# Web commands
Cmnd_Alias WEB_CMDS = /etc/init.d/apache2
In Linux USER_ALIAS is used to group the users where as in Solaris we individually assign a role,profile to user in /etc/user_attr
For example:
# Everybody in the system group "admin" is covered by the alias ADMINS
User_Alias ADMINS = %admin
# The users "tom", "dick", and "harry" are covered by the USERS alias
User_Alias USERS = tom, dick, harry
# The users "tom" and "mary" are in the WEBMASTERS alias
User_Alias WEBMASTERS = tom, mary
# You can also use ! to exclude users from an alias
# This matches anybody in the USERS alias who isn't in WEBMASTERS or ADMINS aliases
User_Alias LIMITED_USERS = USERS, !WEBMASTERS, !ADMINS
Assigning a role or group to commands takes place in a single line in Linux whereas in Solaris we need to first define a role and then we need to independently assign the user to the role.
It takes place in Linux by the following step:
# User privilege specification
root ALL=(ALL) ALL
Here root can run any command from any terminal acting as any user.
# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL
Here user belonging to the admin group can run any command from any terminal acting as any user.
To summarize in Linux it may look more simple to accomplish RBAC ,in Solaris it may look more standarized.sudo and the RBAC implementation accomplish the same basic objectives. The RBAC implementation has a GUI, a finer granularity, and name
service compatibility. Most importantly, sudo is freeware, but RBAC is supported by sun.
For more detailed understanding you may refer to the below url:
http://www.sun.com/software/whitepapers/wp-rbac/wp-rbac.pdf
