The four files

It's important to understand these files and how they relate to each other.

The first file we'll examine is /etc/user_attr. The 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, authorizations, and profiles to users.

The role account has a special shell 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 only exception is the pfexec command.

pfexec allows the user with a role attached directly to their logon account to exececute a role command without first having to switch to a profile shell.

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.

Attribute. An optional list that describes the security attributes to be applied when the user runs the commands or runs a privileged appication. Any or all of the following four valid keys may be contained in this element:

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 group names specified in /etc/security/prof_attr. A profile determines which commands a user can execute.

Roles. Roles can be assigned to the user through a comma-separated list of role names. Roles are defined in the same /etc/user_attr file. Roles cannot be assigned to other roles

Type. Indicates what kind of account this 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 privileged applications that use the solaris.* and solaris.grant authorizations as defined in auth_attr, and can utilize commands that are defined for the profile group, "All".

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 entry, and the role has access to the commands that are allowed by the profiles "Filesystem Management" and "All".

To see what these commands actually are look for the corresponding tag in the /etc/security/exec_attr file.

The second file we'll look at is /etc/security/auth_attr. This file contains authorizations to restricted system functions. Some of these functions include changing the system's 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, Sun recommends that you use your company web address in reverse format (e.g., com.yourcompany.authorization_name).

Certain privileged programs use this file to determine the user's right to execute a 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.

Attribute. 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 /usr/lib/help/auths/locale/C directory.

Some example entries in this file might look like:

solaris.jobs.:::Cron & at Jobs::help=JobHeader.html
solaris.jobs.admin:::Cron & at Jobs Administrator::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 users. Be careful of using .grant as whichever user you give this right to could arbitrarily let other users use these commands as well.

A profile group can be used to bundle together authorizations. Then instead of assigning each individual authorization you simply assign the profile group to the user or role. In some cases the authorizations will also need to run command line tools. The profile group then acts as the middle man as tags from the authorizations are assigned to a profile group and then the profile group name matches a tag in the exec_attr file which then grants access to the command line tools that the authorizations need to get the job done.

The /etc/security/prof_attr file has the following fields:

Profname. The case-sensitive name of the profile.

Res1. Reserved for future use.

Res2. Reserved for future use.

Description. This field should explain why the profile group 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.

Attribute. An optional list that lists entries from /etc/security/auth_attr or other profiles. You could also list a help file here. The help file has the same specifications as described for 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 Removable Media: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 Audit Control in the /etc/security/exec_attr file. The Help file is /usr/lib/help/auths/locale/C/AuditControl.html. In addition, if the user uses an application that needs solaris.audit.config or solaris.jobs.admin authorizations, then they would be able to utilize those programs which require those authorizations. The second example shows the use of a wildcard for authorizations.

The /etc/security/exec_attr file is important to profiles. In it we define exactly which commands the user can run. After you define a profile you may 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. If you omit the user id entry or the group id entries then the program runs as the user's original user id and group id. This might be a little confusing but if you examine the first entry in the file you'll see an entry called: All. This allows the root account or any user account to run any program on the system as their own user id and 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 profile group. Currently there's only one: suser (super-user).

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. There is a caveat with this however. RBAC will not resolve a soft link to it's logical conclusion. A soft link is merely a pointer to a file that may or may not exist. RBAC simply assumes that the file cannot be executed and halts. On the screen this will show up as "cannot execute."

Attribute. An optional list containing one or more of the following followed by a value: uid, euid, gid or egid. The value or name of the user id, effective user id, group id, or effective group id as defined in /etc/passwd or /etc/group. Not all programs will run properly if you use an effective uid or effective gid. You may need to set the program to run as uid or gid instead. You should first try to run them as effective to see if that is possible.

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 rest of the examples show you that the profile group "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. EGID or EUID or analogous to setgroupid or setuserid respectively.

Next Section: Conclusion - 5 of 7