4. Controlling Access and Configuring System Messaging

Objectives

The following test objectives for Exam CX-310-202 are covered in this chapter:

Configure Role-Based Access Control (RBAC), including assigning rights profiles, roles, and authorizations to users.

• This chapter describes Role-Based Access Control (RBAC), and identifies the four main databases involved with RBAC. The system administrator needs to understand the function and structure of each of these databases and how to apply the RBAC functionality in real-world situations.

Analyze RBAC configuration file summaries and manage RBAC using the command line.

• You will see how to assign a role to a user and use rights profiles by using commands that are described in this chapter. These can greatly assist the system administrator when managing a large number of rights that are to be assigned to a number of users.

Explain syslog function fundamentals, and configure and manage the /etc/syslog.conf file and syslog messaging.

• This chapter describes the basics of system messaging in the Solaris operating environment, introduces the daemon responsible for managing the messaging, and describes the configuration file that determines what information is logged and where it is stored. It also describes the new method of restarting/refreshing the syslog process when changes are made to its configuration file.

Outline

Introduction

Role-Based Access Control (RBAC)

Using RBAC

RBAC Components

Extended User Attributes (user_attr) Database

Authorizations (auth_attr) Database

Rights Profiles (prof_attr) Database

Execution Attributes (exec_attr) Database

syslog

Using the logger Command

Summary

Key Terms

Apply Your Knowledge

Exercise

Exam Questions

Answers to Exam Questions

Suggested Reading and Resources

Study Strategies

The following strategies will help you prepare for the test:

• As you study this chapter, it’s important that you practice each exercise and each command that is presented on a Solaris system. Hands-on experience is important when learning these topics, so practice until you can repeat the procedures from memory.

• Be sure you understand each command and be prepared to match the command to the correct description.

• Be sure you know all the terms listed in the “Key Terms” section near the end of this chapter. Pay special attention to the databases used in Role-Based Access Control (RBAC) and the uses and format of each. Be prepared to match the terms presented in this chapter with the correct description.

• Finally, you must understand the concept of system messaging—its purpose, how it works, and how to configure and manage it.

Introduction

This chapter covers two main topics—Role-Based Access Control (RBAC) and system messaging (syslog). These are both related in that they participate in the securing and monitoring of systems in a Solaris environment. The use of Role-Based Access Control makes the delegation of authorizations much easier for the system administrator to manage, as groups of privileges can easily be given to a role through the use of profiles. Also, the use of roles means that a user has to first log in using his or her normal ID and then use the su command to gain access to the role (and therefore assigned privileges). This has the advantage of being logged and therefore helps establish accountability. The system messaging service (syslog) stores important system and security messages and is fully configurable. The system administrator can tune the service so that certain messages are delivered to several places (such as a log file, a message, and the system console), greatly increasing the chances of it being noticed quickly.

Role-Based Access Control (RBAC)

Objectives

• Configure Role-Based Access Control (RBAC) including assigning rights profiles, roles, and authorizations to users.

• Analyze RBAC configuration file summaries and manage RBAC using the command line.

Granting superuser access to nonroot users has always been an issue in UNIX systems. In the past, you had to rely on a third-party package, such as sudo, to provide this functionality. The problem was that sudo was an unsupported piece of freeware that had to be downloaded from the Internet and installed onto your system. In extreme cases, the system administrator had to set the setuid permission bit on the file so that a user could execute the command as root.

With Role-Based Access Control (RBAC) in the Solaris 10 operating environment, administrators can not only assign limited administrative capabilities to nonroot users, they can also provide the mechanism where a user can carry out a specific function as another user (if required). This is achieved through three features:

• Authorizations: User rights that grant access to a restricted function.

• Execution profiles: Bundling mechanisms for grouping authorizations and commands with special attributes; for example, user and group IDs or superuser ID.

• Roles: Special type of user accounts intended for performing a set of administrative tasks.

Using RBAC

To better describe RBAC, it’s easier to first describe how a system administrator would utilize RBAC to delegate an administrative task to a nonroot user in a fictional setting at Acme Corp.

At Acme Corp., the system administrator is overwhelmed with tasks. He decides to delegate some of his responsibility to Neil, a user from the engineering department who helps out sometimes with system administration tasks.

The system administrator first needs to define which tasks he wants Neil to help with. He has identified three tasks:

• Change user passwords, but do not add or remove accounts.

• Mount and share file systems.

• Shut down the system.

In RBAC, when we speak of delegating administrative tasks, it is referred to as a role account. A role account is a special type of user account that is intended for performing a set of administrative tasks. It is like a normal user account in most respects except that users can gain access to it only through the su command after they have logged in to the system with their normal login account. A role account is not accessible for normal logins, for example, through the CDE login window. From a role account, a user can access commands with special attributes, typically the superuser privilege, which are unavailable to users with normal accounts.

At Acme Corp., the system administrator needs to define a role username for the tasks he wants to delegate. Let’s use the role username “adminusr.” After Neil logs in with his normal login name of ncalkins, he then needs to issue the su command and switch to adminusr whenever he wants to perform administrative tasks. In this chapter, you learn how to create a role account using the command line interface, although you should note that the Solaris Management Console can also be used.

So far we have determined that we want to name the role account adminusr. The system administrator creates the role account using the roleadd command. The roleadd command adds a role account to the /etc/passwd, etc/shadow, and /etc/user_attr files. The syntax for the roleadd command is as follows:

roleadd [-c comment] [-d dir] [-e expire] [-f inactive] [-g group]
[-G group] [-m] [-k skel_dir] [-u uid] [-s shell]
[-A authorization] [-P profile ] <role username>

You’ll notice that roleadd looks a great deal like the useradd command. Table 4.1 describes the options for the roleadd command.

Table 4.1 roleadd Options

The other options are the same options that were described for the useradd command, outlined in Solaris 10 System Administration Exam Prep: CX-310-200, Part I.

When creating a role account with the roleadd command, you need to specify an authorization or profile to the role. An authorization is a user right that grants access to a restricted function. It is a unique string that identifies what is being authorized as well as who created the authorization.

Certain privileged programs check the authorizations to determine whether users can execute restricted functionality. Following are the predefined authorizations from the /etc/security/auth_attr file that apply to the tasks to be delegated:

solaris.admin.usermgr.pswd:::Change Password::help=AuthUserMgrPswd.html
solaris.system.shutdown:::Shutdown the System::help=SysShutdown.html
solaris.admin.fsmgr.write:::Mount and Share File Systems::
help=AuthFsMgrWrite.html

All authorizations are stored in the auth_attr database, so the system administrator needs to use one or more of the authorizations that are stored in that file. For the Acme Corp. example, the system administrator needs to specify the authorizations shown here:

solaris.admin.usermgr.pswd
solaris.system.shutdown
solaris.admin.fsmgr.write

The system administrator would therefore issue the roleadd command as follows:

# roleadd -m -d /export/home/adminusr -c “Admin Assistant”
-A solaris.admin.usermgr.pswd,solaris.system.shutdown,
solaris.admin.fsmgr.write adminusr<cr>

A role account named adminusr with the required directory structures has been created. The next step is to set the password for the adminusr role account by typing the following:

passwd adminusr

You are prompted to type the new password twice.

Now we need to set up Neil’s account so he can access the new role account named adminusr. With the usermod command, we assign the role to the user account using the -R option:

usermod -R adminusr neil

To access the administrative functions, Neil needs to first log in using his regular user account named neil. Neil can check which roles he has been granted by typing the following at the command line:

$ roles<cr>

The system responds with the roles that have been granted to the user account neil:

adminusr

Neil then needs to su to the adminusr account by typing the following:

$ su adminusr<cr>

Neil is prompted to type the password for the role account.

Now Neil can modify user passwords, shut down the system, and mount and share file systems. Any other user trying to su to the adminusr account gets this message:

$ su adminusr<cr>
Password:
Roles can only be assumed by authorized users
su: Sorry
$

If the system administrator later wants to assign additional authorizations to the role account named adminusr, he would do so using the rolemod command. The rolemod command modifies a role’s login information on the system. The syntax for the rolemod command is as follows:

rolemod [-u uid] [-o] [-g group] [-G group] [-d dir] [-m] [-s shell]
[-c comment] [-l new_name] [-f inactive] [-e expire] [-A Authorization]
[-P profile] <role account>

Table 4.2 describes options for the rolemod command where they differ from the roleadd command.

Table 4.2 rolemod Options

To add the ability to purge log files, you need to add solaris.admin.logsvc.purge to the list of authorizations for adminusr. To do this, issue the rolemod command:

# rolemod -A solaris.admin.usermgr.pswd,solaris.system.shutdown,
solaris.admin.fsmgr.write,solaris.admin.logsvc.purge adminusr<cr>

You can verify that the new authorizations have been added to the role by typing the auths command at the command line:

# auths adminusr<cr>
solaris.admin.usermgr.pswd,solaris.system.shutdown,solaris.admin.fsmgr.
write,solaris.admin.logsvc.purge,...
[ output has been truncated]

If you want to remove a role account, use the roledel command:

roledel [-r] <role account name>

The -r option removes the role’s home directory from the system. For example, to remove the adminusr role account, issue the following command:

# roledel -r adminusr<cr>

The next section discusses each of the RBAC databases in detail, describing the entries made when we executed the roleadd and usermod commands.

RBAC Components

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

• /etc/user_attr (extended user attributes database): Associates users and roles with authorizations and profiles.

• /etc/security/auth_attr (authorization attributes database): Defines authorizations and their attributes and identifies the associated help file.

• /etc/security/prof_attr (rights profile attributes database): Defines profiles, lists the profile’s assigned authorizations, and identifies the associated help file.

• /etc/security/exec_attr (profile attributes database): Defines the privileged operations assigned to a profile.

These four databases are logically interconnected.

Extended User Attributes (user_attr) Database

The /etc/user_attr database supplements the passwd and shadow databases. It contains extended user attributes, such as authorizations and profiles. It also allows roles to be assigned to a user. Following is an example of the /etc/user_attr database:

The following fields in the user_attr database are separated by colons:

user:qualifier:res1:res2:attr

Each field is described in Table 4.3.

Table 4.3 user_attr Fields

In the previous section, we issued the following roleadd command to add a role named adminusr:

# roleadd -m -d /export/home/adminusr -c “Admin Assistant”
 -A solaris.admin.usermgr.pswd,solaris.system.shutdown,
solaris.admin.fsmgr.write adminusr<cr>

The roleadd command made the following entry in the user_attr database:

adminusr::::type=role;auths=solaris.admin.usermgr.pswd,
solaris.system.shutdown,solaris.admin.fsmgr.write;profiles=All

We can then issue the following usermod command to assign the new role to the user neil:

# usermod -R useradmin neil<cr>

and then make the following entry to the user_attr database:

neil::::type=normal;roles=adminusr

Authorizations (auth_attr) Database

An authorization is a user right that grants access to a restricted function. In the previous section, the system administrator wanted to delegate some of the system administrative tasks to Neil. Assigning authorizations to the role named adminusr did this. An authorization is a unique string that identifies what is being authorized as well as who created the authorization. Remember that we used the following authorizations to give Neil the ability to modify user passwords, shut down the system, and mount and share file systems:

solaris.admin.usermgr.pswd
solaris.system.shutdown
solaris.admin.fsmgr.write

Certain privileged programs check the authorizations to determine whether users can execute restricted functionality. For example, the solaris.jobs.admin authorization is required for one user to edit another user’s crontab file.

All authorizations are stored in the auth_attr database. If no name service is used, the database is located in a file named /etc/security/auth_attr. Authorizations can be assigned directly to users (or roles), in which case they are entered in the user_attr database. Authorizations can also be assigned to profiles, which in turn are assigned to users. They are described in the “Rights Profiles (prof_attr) Database” section, later in this chapter.

The fields in the auth_attr database are separated by colons, as shown here:

authname:res1:res2:short_desc:long_desc:attr

Each field is described in Table 4.4.

Table 4.4 auth_attr Fields

The following are some typical values found in the default auth_attr database:

solaris.admin.usermgr.pswd:::Change Password::help=AuthUserMgrPswd.html
solaris.system.shutdown:::Shutdown the System::help=SysShutdown.html
solaris.admin.fsmgr.write:::Mount and Share File Systems::
help=AuthFsMgrWrite.html

Look at the relationship between the auth_attr and the user_attr databases for the adminusr role we added earlier:

adminusr::::type=role;auths=solaris.admin.usermgr.pswd,
solaris.system.shutdown,solaris.admin.fsmgr.write;profiles=All

Notice the authorization entries that are bold. These authorization entries came out of the auth_attr database, shown previously. The solaris.system.shutdown authorization, which is defined in the auth_attr database, gives the role the right to shut down the system.

Rights Profiles (prof_attr) Database

We referred to rights profiles, or simply profiles, earlier in this chapter. Up until now, we assigned authorization rights to the role account. Defining a role account that has several authorizations can be tedious. In this case, it’s better to define a profile, which is several authorizations bundled together under one name called a profile name. The definition of the profile is stored in the prof_attr database. Following is an example of a profile named Operator, which is in the default prof_attr database. Again, if you are not using a name service, the prof_attr file is located in the /etc/security directory.

Operator:::Can perform simple administrative tasks:profiles=Printer
Management,Media Backup,All;help=RtOperator.html

Several other profiles are defined in the prof_attr database. Colons separate the fields in the prof_attr database:

profname:res1:res2:desc:attr

The fields are defined in Table 4.5.

Table 4.5 prof_attr Fields

Perhaps the system administrator wants to create a new role account and delegate the task of printer management and backups. He could look through the auth_attr file for each authorization and assign each one to the new role account using the roleadd command, as described earlier. Or, he could use the Operator profile currently defined in the prof_attr database, which looks like this:

The Operator profile consists of three other profiles:

• Printer Management

• Media Backup

• All

Let’s look at each of these profiles as defined in the prof_attr database:

Printer Management:::Manage printers, daemons, spooling:help=RtPrntAdmin.
html;auths=solaris.admin.printer.read,solaris.admin.printer.modify,
solaris.admin.printer.delete
Media Backup:::Backup files and file systems:help=RtMediaBkup.html
All:::Execute any command as the user or role:help=RtAll.html

Printer Management has the following authorizations assigned to it:

• solaris.admin.printer.read

• solaris.admin.printer.modify

• solaris.admin.printer.delete

When you look at these three authorizations in the auth_attr database, you see the following entries:

solaris.admin.printer.read:::View Printer Information::help=AuthPrinterRead.html
solaris.admin.printer.modify:::Update Printer Information::help=AuthPrinterModify.html
solaris.admin.printer.delete:::Delete Printer Information::help=AuthPrinterDelete.html

Assigning the Printer Management profile is the same as assigning the three authorizations for viewing, updating, and deleting printer information.

The Media Backup profile provides authorization for backing up data, but not restoring data. The Media Backup profile does not have authorizations associated with it like the Printer Management profile has. I’ll describe how this profile is defined in the next section when I describe execution attributes.

The All profile grants the right for a role account to use any command when working in an administrator’s shell. These shells can only execute commands that have been explicitly assigned to a role account through granted rights. We’ll explore this concept further when I describe execution attributes in the next section.

To create a new role account named admin2 specifying the Operator profile, use the roleadd command with the -P option:

# roleadd -m -d /export/home/admin2 -c “Admin Assistant” -P Operator admin2<cr>

The following entry is added to the user_attr database:

admin2::::type=role;profiles=Operator

At any time, users can check which profiles have been granted to them with the profiles command:

$ profiles<cr>

The system lists the profiles that have been granted to that particular user account.

Execution Attributes (exec_attr) Database

An execution attribute associated with a profile is a command (with any special security attributes) that can be run by those users or roles to which the profile is assigned. For example, in the previous section, we looked at the profile named Media Backup in the prof_attr database. Although no authorizations were assigned to this profile, the Media Backup profile was defined in the exec_attr database as follows:

The fields in the exec_attr database are as follows and are separated by colons:

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

The fields are defined in Table 4.6.

Table 4.6 exec_attr Fields

Looking back to the Media Backup profile as defined in the exec_attr database, we see that the following commands have an effective UID of 0 (superuser):

/usr/bin/mt
/usr/sbin/tar
/usr/lib/fs/ufs/ufsdump

Therefore, any user that has been granted the Media Backup profile can execute the previous backup commands with an effective user ID of 0 (superuser).

In the prof_attr database, we also saw that the Operator profile consisted of a profile named All. Again, All did not have authorizations associated with it. When we look at the exec_attr database for a definition of the All profile, we get the following entry:

All:suser:cmd:::*:

Examining each field, we see that All is the profile name, the security policy is suser, and the type of entity is cmd. The attribute field has an *.

It’s common to grant all users the All profile. The * is a wildcard entry that matches every command. In other words, the user has access to any command while working in the shell. Without the All profile, a user would have access to the privileged commands, but no access to normal commands such as ls and cd. Notice that no special process attributes are associated with the wildcard, so the effect is that all commands matching the wildcard run with the UID and GID of the current user (or role).

syslog

Objective

• Explain syslog function fundamentals and configure and manage the /etc/syslog.conf file and syslog messaging.

A critical part of the system administrator’s job is monitoring the system. Solaris uses the syslog message facility to do this. syslogd is the daemon responsible for capturing system messages. The messages can be warnings, alerts, or simply informational messages. As the system administrator, you customize syslog to specify where and how system messages are to be saved.

The syslogd daemon receives messages from applications on the local host or from remote hosts and then directs messages to a specified log file. To each message that syslog captures, it adds a timestamp, the message type keyword at the beginning of the message, and a new-line at the end of the message. For example, the following messages were logged in the /var/adm/messages file:

July 15 23:06:39 sunfire ufs: [ID 845546 kern.notice] NOTICE: alloc: /var:
file system full
Sep 1 04:57:06 docbert nfs: [ID 563706 kern.notice] NFS server saturn.east ok

syslog enables you to capture messages by facility (the part of the system that generated the message) and by level of importance. Facility is considered to be the service area generating the message or error (such as printing, email, or network), whereas the level can be considered the level of severity (such as notice, warning, error, or emergency). syslog also enables you to forward messages to another machine so that all your messages can be logged in one location. The syslogd daemon reads and logs messages into a set of files described by the configuration file /etc/syslog.conf. When the syslogd daemon starts up, it preprocesses the /etc/syslog.conf file through the m4 macro processor to get the correct information for specific log files. syslogd does not read the /etc/syslog.conf file directly. syslogd starts m4, which parses the /etc/syslog.conf file for ifdef statements that can be interpreted by m4. The function ifdef is an integral part of m4 and identifies the system designated as LOGHOST. The macro then can evaluate whether log files are to be held locally or on a remote system, or a combination of both.

If m4 doesn’t recognize any m4 commands in the syslog.conf file, output is passed back to syslogd. syslogd then uses this output to route messages to appropriate destinations. When m4 encounters ifdef statements that it can process, the statement is evaluated for a true or false condition and the message is routed relative to the output of the test.

An entry in the /etc/syslog.conf file is composed of two fields:

selector   action

The selector field contains a semicolon-separated list of priority specifications of this form:

facility.level [ ; facility.level ]

The action field indicates where to forward the message. Many defined facilities exist.

The facilities are described in Table 4.7.

Table 4.7 Recognized Values for Facilities

Table 4.8 lists recognized values for the syslog level field. They are listed in descending order of severity.

Table 4.8 Recognized Values for level

Values for the action field can have one of four forms:

• A filename, beginning with a leading slash. This indicates that messages specified by the selector are to be written to the specified file. The file is opened in append mode and must already exist. syslog does not create the file if it doesn’t already exist.

• The name of a remote host, prefixed with a @. An example is @server, which indicates that messages specified by the selector are to be forwarded to syslogd on the named host. The hostname loghost is the hostname given to the machine that will log syslogd messages. Every machine is its own loghost by default. This is specified in the local /etc/hosts file. It is also possible to specify one machine on a network to be loghost by making the appropriate host table entries. If the local machine is designated as loghost, syslogd messages are written to the appropriate files. Otherwise, they are sent to the machine loghost on the network.

• A comma-separated list of usernames, which indicates that messages specified by the selector are to be written to the named users if they are logged in.

• An asterisk, which indicates that messages specified by the selector are to be written to all logged-in users.

Blank lines are ignored. Lines in which the first nonwhitespace character is a # are treated as comments.

All of this becomes much clearer when you look at sample entries from an /etc/syslog.conf file:

In this example, the first line prints all errors on the console.

The second line sends all errors, daemon and authentication system notices, and critical errors from the mail system to the file /var/adm/messages.

The third line sends mail system debug messages to /var/log/syslog.

The fourth line sends all alert messages to user root.

The fifth line sends all emergency messages to all users.

The sixth line forwards kernel messages of err (error) severity or higher to the machine named server.

The last line logs all alert messages and messages of warning level or higher from the authorization system to the file /var/log/auth.

The level none may be used to disable a facility. This is usually done in the context of eliminating messages. For example:

*.debug;mail.none /var/adm/messages

This selects debug messages and above from all facilities except those from mail. In other words, mail messages are disabled. The mail system, sendmail, logs a number of messages. The mail system can produce a large amount of information, so some system administrators disable mail messages or send them to another file that they clean out frequently. Before disabling mail messages, however, remember that sendmail messages come in very handy when you’re diagnosing mail problems or tracking mail forgeries.

As of Solaris 10, the mechanism for stopping, starting, and refreshing syslogd has changed. The syslog function is now under the control of the Service Management Facility (SMF), which is described in detail in the book Solaris 10 System Administration Exam Prep: CX-310-200, Part I.

To stop or start syslogd, use the svcadm command with the appropriate parameter, enable or disable:

# svcadm enable -t system-log<cr>
# svcadm disable -t system-log<cr>

The syslog facility reads its configuration information from /etc/syslog.conf whenever it receives a refresh command from the service administration command, svcadm, and when the system is booted. You can make your changes to /etc/syslog.conf and then run the following command to cause the file to be reread by the syslogd daemon:

# svcadm refresh system-log<cr>

The first message in the log file is logged by the syslog daemon itself to show when the process was started.

syslog logs are automatically rotated on a regular basis. In previous Solaris releases, this was achieved by the program newsyslog. A new method of log rotation was introduced with Solaris 9—logadm, a program normally run as a root-owned cron job. A configuration file /etc/logadm.conf is now used to manage log rotation and allows a number of criteria to be specified. See the logadm and logadm.conf manual pages for further details.

Using the logger Command

The logger command provides the means of manually adding one-line entries to the system logs from the command line. This is especially useful in shell scripts.

The syntax for the logger command is as follows:

logger [-i] [-f file] [-p priority] [-t tag] [message] ...

Options to the logger command are described in Table 4.9.

Table 4.9 logger Options

For example, perhaps you have a simple shell script that backs up files:

#/bin/ksh
tar cvf /tmp/backup .
logger -p user.alert “Backups Completed”

The last line of the script uses the logger command to send a “Backups Completed” message to the default system log (/var/adm/messages). After running the script, I see the following message appended to the log file:

Jan 23 14:02:52 sunfire root: [ID 702911 user.alert] Backups Completed

Summary

In this chapter you learned about Role-Based Access Control (RBAC), which allows the system administrator to delegate administrative responsibilities to users without having to divulge the root password. A number of profiles allow privileges to be grouped together so that a user can easily be granted a restricted set of additional privileges. Four main RBAC databases interact with each other to provide users with access to privileged operations:

• /etc/security/auth_attr: Defines authorizations and their attributes and identifies the associated help file.

• /etc/security/exec_attr: Defines the privileged operations assigned to a profile.

• /etc/security/prof_attr: Defines the profiles, lists the profile’s assigned authorizations, and identifies the associated help file.

• /etc/user_attr: Associates users and roles with authorizations and execution profiles.

Also in this chapter, you learned about the system logging facility (syslog) and the configuration that facilitates routing of system messages according to specific criteria, as well as determining where the messages are logged. The logger command was covered, which allows the system administrator to enter ad-hoc messages into the system log files.

Key Terms

• Authorization

• Execution profile

• logger

• RBAC

• RBAC databases (know about all four)

• Rights profile

• Role

• syslog

• svcadm command

Apply Your Knowledge

Exercise

4.1 Creating a User and a Role

In this exercise, you’ll create a new role named admin1 and a profile called Shutdown. The Shutdown profile will be added to the role. A user account trng1 will be created and have the admin1 role assigned to it. The user will then assume the role and execute a privileged command to shut down the system.

Estimated time: 20 minutes

To create a user and a role, follow these steps:

1. Create the role named admin1:

# roleadd -u 2000 -g 10 -d /export/home/admin1 -m admin1<cr> #
passwd admin1<cr>

You are prompted to enter the password twice.

2. Create a profile to allow the user to shut down a system.

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

Shutdown:::Permit system shutdown:

Save and exit the file.

3. Add the Shutdown and All profiles to the role:

# rolemod -P Shutdown,All admin1<cr>

4. Verify that the changes have been made to the user_attr database:

# more /etc/user_attr<cr>

5. Create the user account and assign it access to the admin1 role:

# useradd -u 3000 -g 10 -d /export/home/trng1 -m -s /bin/ksh -R admin1 trng1<cr>

6. Assign a password to the new user account:

# passwd trng1<cr>

You are prompted to enter the password twice.

7. Verify that the entry has been made to the passwd, shadow, and user_attr files:

# more /etc/passwd<cr>
# more /etc/shadow<cr>
# more /etc/user_attr<cr>

8. Assign commands to the Shutdown profile:

Edit the /etc/security/exec_attr file and add the following line:

Shutdown:suser:cmd:::/usr/sbin/shutdown:uid=0

Save and exit the file.

9. Test the new role and user account as follows:

a. Log in as trng1.

b. List the roles that are granted to you by typing the following:

$ roles<cr>

c. Use the su command to assume the role admin1:

$ su admin1<cr>

You are prompted to enter the password for the role.

d. List the profiles that are granted to you by typing the following:

$ profiles<cr>

e. Shut down the system:

$ /usr/sbin/shutdown -i 0 -g 0<cr>

Exam Questions

1. Which of the following commands is used to create a role?

• A. useradd

• B. makerole

• C. roleadd

• D. addrole

2. In Role-Based Access Control, which file contains details of the user attributes?

• A. /etc/security/prof_attr

• B. /etc/user_attr

• C. /etc/security/user_attr

• D. /etc/shadow

3. Which two statements about the roleadd command are true? (Choose two.)

• A. roleadd looks similar to the useradd command.

• B. roleadd uses the profile shell (pfsh) as the default shell.

• C. The -A option associates an account with a profile.

• D. An account created with roleadd is the same as a normal login account.

4. Which component of RBAC associates users and roles with authorizations and profiles?

• A. user_attr

• B. prof_attr

• C. auth_attr

• D. exec_attr

5. Which component of RBAC defines the privileged operations assigned to a profile?

• A. user_attr

• B. prof_attr

• C. auth_attr

• D. exec_attr

6. In the execution attributes database, which of the following is not a valid value for the attr field?

• A. euid

• B. uid

• C. egid

• D. suid

7. After creating an RBAC role, you find that the only commands that can be executed within the role are the privileged commands that you have set up. Ordinary nonprivileged commands are not available. The RBAC setup has a problem. What is the cause of this problem?

• A. The role is not associated with a correct profile.

• B. The access mechanism to the role is not initializing properly.

• C. The role’s profile is not associated with the correct commands.

• D. The file identifying the privileged commands has missing entries.

• E. The role’s profile is not associated with the correct authorizations.

8. Which of the following are valid RBAC databases? (Choose three.)

• A. /etc/usr_attr

• B. /etc/user_attr

• C. /etc/security/exec_attr

• D. /etc/security/prof_attr

9. You want to enable a user to administer all user cron tables. This includes amending entries in any user’s crontab. Given due care to system security, what should you do to enable the user to carry out this duty?

• A. Give the user the root password.

• B. Set the suid on the crontab command.

• C. Use RBAC to authorize the user to administer cron tables.

• D. Use RBAC to give the user an ID of root when executing the crontab command.

• E. Use the ACL mechanism to give the user RW access to each crontab table.

10. Which command(s) grant a user access to a role account? (Choose two.)

• A. roleadd

• B. rolemod

• C. useradd

• D. usermod

11. Which option to the rolemod command appends an authorization to an exiting list of authorizations?

• A. -A

• B. -P

• C. -a

• D. -o

• E. None

12. In which files are profiles defined? Choose all that apply. (Choose two.)

• A. /etc/security/prof_attr

• B. /etc/user_attr

• C. /etc/security/exec_attr

• D. /etc/security/auth_attr

13. Which statements are true regarding the following line? (Choose all that apply.)

Media Restore:suser:cmd:::/usr/lib/fs/ufs/ufsrestore:euid=0

• A. It represents a profile in the exec_attr database.

• B. Any role that has Media Restore as a profile can execute the ufsrestore command with an effective UID of root.

• C. It represents a profile in the prof_attr database.

• D. It represents a role definition in the user_attr database.

14. In RBAC, which of the following is a bundling mechanism for grouping authorizations and commands with special attributes?

• A. Profile

• B. Role

• C. Authorization

• D. Group

Answers to Exam Questions

1. C. Use the roleadd command to create a role account. For more information, see the “Using RBAC” section.

2. B. /etc/user_attr contains details of the extended user attributes.
For more information, see the “RBAC Components” section.

3. A, B. The roleadd command looks very similar to the useradd command, but it uses the profile shell as the default shell. For more information, see the “Using RBAC” section.

4. A. user_attr (extended user attributes database) associates users and roles with authorizations and profiles. For more information, see the “RBAC Components” section.

5. D. exec_attr (profile attributes database) defines the privileged operations assigned to a profile. For more information, see the “RBAC Components” section.

6. D. Six valid keys exist: euid, uid, egid, gid, privs, and limitprivs. For more information, see the “RBAC Components” section.

7. A. If a role is not associated with a correct profile, the only commands that can be executed within the role are the privileged commands that you have set up. Ordinary nonprivileged commands are unavailable. For more information, see the “RBAC Components” section.

8. B, C, D. The three valid RBAC databases are /etc/user_attr, /etc/security/exec_attr, and /etc/security/prof_attr. For more information, see the “RBAC Components” section.

9. C. To enable a user to administer all user cron tables, configure RBAC to authorize the user to administer cron tables. For more information, see the “Using RBAC” section.

10. C, D. Use the roleadd command to create a role account. Then, with the usermod command, assign the role to an existing user account using the -R option. If you are creating a new user account, use the useradd command with the -R option to assign the role to the new user account. For more information, see the “Using RBAC” section.

11. E. The rolemod command does not add to the existing authorizations; it replaces any existing authorization setting. For more information, see the “Using RBAC” section.

12. A, C. /etc/security/prof_attr (rights profile attributes database) defines profiles, lists the profile’s assigned authorizations, and identifies the associated help file. /etc/security/exec_attr (profile attributes database) defines the privileged operations assigned to a profile. For more information, see the “RBAC Components” section.

13. A, B. The following entry in the exec_attr database represents a profile named Media Restore:

Media Restore:suser:cmd:::/usr/lib/fs/ufs/ufsrestore:euid=0

Any role that has Media Restore as a profile can execute the ufsrestore command with an effective UID of root. For more information, see the “RBAC Components” section.

14. A. Execution profiles are bundling mechanisms for grouping authorizations and commands with special attributes. For more information, see the “RBAC Components” section.

Suggested Reading and Resources

Solaris 10 Documentation CD: “Security Services” and “System Administration Guide: Advanced Administration” manuals.

http://docs.sun.com. Solaris 10 documentation set: “Security Services” and “System Administration Guide: Advanced Administration” books in the System Administration collection.