The goal of an access control system is to limit
access to resources based on a set of constraints. Typically, these
constraints and their associated attributes fit into the following
categories:
Subject: The entity attempting
to access the resource. In the context of an operating system, the
subject is commonly a user or a process associated with a user.
Operation: An action performed on
a resource. An operation can correspond directly to an application
or a command. In the case of HP-UX RBAC, the operation is a dot-separated,
hierarchical string, such as hpux.user.add.
Object: The target of the operation,
which is often the same as the end resource, but which can be different.
An access control request can be thought of as
a question combining the previous elements, where the response to
the question (usually allow or deny) determines whether access to
the resource is granted. For example:
Is the user ron authorized to
perform the operation hpux.fs.mount on the object/dev/dsk/c0t1d0?
Often, the term authorization is used as a synonym
for access control. In HP-UX RBAC, authorization refers to the ability
to perform an operation on an object. As shown in Table 9-1, a user can have a set of
authorizations, each of which allows access to a resource.
Table 9-1 Example of Authorizations Per User
Operation Component of Authorization | Users |
|---|
| ron | lisa | jim | liz |
hpux.user.add | | | | |
hpux.user.delete | | | | |
hpux.user.modify | | | | |
hpux.user.password.modify | • | • | • | • |
hpux.network.nfs.start | • | | | |
hpux.network.nfs.stop | • | | | |
hpux.network.nfs.config | • | | | |
hpux.fs.backup | • | • | | |
hpux.fs.restore | • | • | | |
 |
| |
|
 | NOTE: Table 9-1 shows
only the operation element of the authorizations—not the object
element of the authorizations. |
|
| |
|
Simplifying Access Control with Roles |
|
In addition to the basic principals of access control discussed
in the preceding overview, this section addresses how access control
policy is represented and how decisions are made.
The preceding overview of access control does not
address how access control policy is represented and how decisions
are made. One approach is to simply maintain a list of users and the
authorizations (operation, object pairs) assigned to each of them.
This approach has the advantage of being flexible, because each user's
set of authorizations can be completely different from those of the
other users.
Unfortunately, this approach is also difficult
to manage because as you add users, you must determine exactly which
authorizations each user requires. Also, when performing audits, you
must examine each user individually to determine his or her associated
authorizations.
HP-UX RBAC addresses these issues by grouping users
with common authorization needs into roles. Roles serve as a grouping
mechanism to simplify authorization assignment and auditing. Rather
than assigning an authorization directly to a user, you assign authorizations
to roles. As you add users to the system, you assign them a set of
roles, which determine the actions they can perform and the resources
they can access.
Compare Table 9-2, which lists authorizations assigned to roles, with Table 9-1, which lists authorizations
assigned to each user. By comparing these two tables, you can see
how roles simplify authorization assignment.
Table 9-2 Example of Authorizations Per Role
Operation Component of Authorization | Role |
|---|
| UserAdmin | NetworkAdmin | BackupOper | Admin |
hpux.user.add | • | | | • |
hpux.user.delete | • | | | • |
hpux.user.modify | • | | | • |
hpux.user.password.modify | | | | • |
hpux.network.nfs.start | | • | | • |
hpux.network.nfs.stop | | • | | • |
hpux.network.nfs.config | | • | | • |
hpux.fs.backup | | | • | • |
hpux.fs.restore | | | • | • |
|
| |
|
| NOTE: Table 9-2 shows
only the operation element of the authorizations—not the object
element of the authorization. |
|
| |
|
Printable version
