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_attr Database).
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_attr database 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 the prof_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 with euid 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
|
RBAC Commands
This section lists commands that are used to administer RBAC. Also provided is a table of commands whose access can be controlled by authorizations.
Command-Line Applications for Managing RBAC
In addition to editing the RBAC databases directly, the following commands are available for managing access to tasks with RBAC.
Table 7-7 RBAC Administration Commands
Command | Description |
|---|
auths(1) | Displays authorizations for a user. |
makedbm(1M) | Makes a dbm file. |
nscd(1M) | Name service cache daemon, useful for caching the user_attr, prof_attr, and exec_attr databases. |
pam_roles(5) | Role account management module for PAM. Checks for
the authorization to assume role. |
pfexec(1) | Used by profile shells to execute commands with attributes
that are specified in the exec_attr database. |
policy.conf(4) | Configuration file for security policy. Lists
granted authorizations. |
profiles(1) | Displays rights profiles for a specified user. |
roles(1) | Displays roles that are granted to a user. |
roleadd(1M) | Adds a role to the system. |
roledel(1M) | Deletes a role from the system. |
rolemod(1M) | Modifies a role's properties on the system. |
smattrpop(1M) | Merges the source security
attribute database into the target database. For use in situations where local databases need to be merged into a name service and in upgrades where conversion scripts are not supplied. |
smexec(1M) | Manages entries in the exec_attr
database. Requires authentication. |
smmultiuser(1M) | Manages bulk operations on user accounts.
Requires authentication. |
smuser(1M) | Manages user entries. Requires authentication. |
smprofile(1M) | Manages rights profiles in the prof_attr and exec_attr databases. Requires authentication. |
smrole(1M) | Manages roles and users in role accounts. Requires authentication. |
useradd(1M) | Adds a user account to the system. The -P
option assigns a role to a user's account. |
userdel(1M) | Deletes a user's login from the system. |
usermod(1M) | Modifies a user's account properties on the system. |
Commands That Require Authorizations
The following table provides examples of how authorizations are used to limit command options in the Solaris environment. See also Authorizations.
Table 7-8 Commands and Associated Authorizations
Commands | Authorization Requirements |
|---|
at(1) | solaris.jobs.user required for all options (when neither at.allow
nor at.deny files exist) |
atq(1) | solaris.jobs.admin required for all options |
crontab(1) | solaris.jobs.user required for the option to submit a job (when neither crontab.allow nor crontab.deny files exist) solaris.jobs.admin required for the options to list or modify other users' crontab files |
allocate(1) (with BSM enabled only) | solaris.device.allocate (or other authorization
as specified in device_allocate(4)) required to allocate a device. solaris.device.revoke (or other authorization
as specified in device_allocate file) required to allocate a device to another user (-F option) |
deallocate(1) (with BSM enabled only) | solaris.device.allocate (or other authorization
as specified in device_allocate(4)) required to deallocate another user's device. solaris.device.revoke (or
other authorization as specified in device_allocate) required to force deallocation of the specified device (-F option) or all devices (-I option) |
list_devices(1) (with BSM enabled only) | solaris.device.revoke required to list another user's devices (-U option) |
| 
Previous