security(5) DG/UX B2 Security R4.12MU02 security(5)
NAME
security - Introduction to DG/UX information security options.
DESCRIPTION
This man page is an introduction to information security on the DG/UX
system. It describes basic DG/UX information security options and
related terminology.
DEFINITIONS
Information Security Options
An enhancement to the standard DG/UX system, consisting of security
mechanisms that better protect information from unauthorized access
and perform other security functions. Among the major provisions of
an information security option are additional access control
policies, policies that restrict access to information and other
resources in specific ways.
In this man page, we refer to the target of an operation as an
object. Likewise, we refer to a process that causes information to
flow among objects, or changes the system state, as a subject. In
this terminology, a security policy protects objects from
unauthorized access by subjects.
There are three distinct access control policies on the DG/UX System:
discretionary access control (DAC), mandatory access control (MAC),
and capability access control (CAC). Each of these policies uses its
own access control attributes, parameters associated with subjects
and objects for implementation purposes. A policy may act to protect
both information and access control attributes. Therefore, we
sometimes distinguish between an information access policy and an
attribute access policy, both of which are integral parts of the same
access control policy.
The DG/UX System supports access control overrides, which allow
negative decisions from access control policies to be reversed in
some cases. Specifically, a process may be able to override a
negative decision from the MAC or DAC policies, but there is no
override for a CAC failure. The system routes all access requests to
the Reference Monitor (RM), the functional unit that arbitrates all
access between subjects and objects on the system.
Currently there are two product models that provide extended security
features. The C2 Trusted option provides security features and
assurances consistent with a C2 level of trust. The security policies
are configurable and conform to the C2 requirements for DAC and
auditing and provide a fine-grained authentication and authorization
mechanism.
The B2 Security Option provides security features and assurances
consistent with a B2 level of trust. These security policies are also
configurable and meet or exceed the B2 requirements for DAC, MAC, and
CAC. In addition to a service-based fine-grained authentication and
authorization mechanism, the B2 Security option supports a trusted
path between the user and the system, reduces administrative risk
through the provision of multiple administrative roles, prevents the
threat associated with viruses, and provides trusted networking
according to the DNSIX protocol.
This man page discusses the security feature set in general. Refer to
product documentation for information about specific features
available with each model.
Trusted Path
Trusted Path provides users an assured way to access system session
control services. By using Trusted Path, users can be assured they
are interacting with system services provided by the Trusted
Computing Base (TCB) rather than another user program that simulates
system service to fraudulently obtain passwords or other information.
Trusted IP
Trusted IP provides a mechanism to associate security attributes with
Network Sessions. The exact set of security attributes depends on
the configuration of the system and the network; attributes such as
MAC labels, capabilities, Authentication IDs, and user IDs are often
transmitted between machines. When a network session is established,
Trusted IP makes the attributes of the remote peer available to the
local peer. Trusted IP also ensures that Mandatory Access Control is
enforced and session events are audited.
Capability Mechanism
A mechanism that breaks the privileges supported on a DG/UX System
into a set of discrete capabilities that the system may confer upon a
subject. The capability mechanism is used to allow the division of
administrative privilege on the system amongst several roles. This
allows a DG/UX System to enforce the principle of least privilege,
defined by the National Computer Security Center as "...the principle
that requires that each subject be granted the most restrictive set
of privileges needed for the performance of authorized tasks".
The capability concept is best illustrated through comparison with
the workings of a standard DG/UX System. In a standard system, user
privileges revolve around an all-powerful superuser, a process with
an effective user ID of 0, which is granted special privileges. (For
example, the su(2) command does not query the superuser for a
password.) The system enforces the distinction between the superuser
and other users by checking the invoker's effective UID for superuser
status when executing commands.
The basis for the capability mechanism is not the superuser, but the
notion of appropriate privilege, which allows the system to grant
privileges to subjects in a more flexible manner. Appropriate
privilege denotes a subject's ability to perform a given restricted
operation or to override an access control policy, as determined by
three mechanisms:
events:
places in the code where security-related decisions are made
or recorded. These consist of operational events, which
determine whether a subject has the capabilities required to
perform an operation; access events, which determine whether a
subject has access rights to an object with respect to an
access control policy; access override events, which determine
whether a subject may override a negative decision on an
access event; and audit events, which record security-relevant
changes to the system state.
operations:
requests for service that can be invoked from the system. Some
operations are restricted, in which case an operational event
is used to determine whether the invoker has the appropriate
privileges to perform the operation.
capabilities:
privileges that the system can confer upon a subject. A
subject's capabilities make explicit its ability to perform
restricted operations or to override an access control policy.
The system confers capabilities on a subject in accordance with the
principle of least privilege. This is done through the use of
administrative roles and capability sets.
An administrative role is a user account that couples a special set
of tasks with the privileges needed to perform those tasks. A user
assumes an administrative role through the assume(1) command, which
initiates a new session having the privileges associated with the
role. Each system with the capability mechanism present supports a
number of pre-defined administrative roles with default capability
settings. In addition, the capability mechanism allows for the
creation of additional administrative roles to suit the needs of
individual sites. These roles enable the system to restrict
administrative operations to users with appropriate privilege, and to
limit administrative risk by distributing among users the privileges
formerly accorded to the superuser. Common roles are the sysadmin
role, used to manage the day-to-day administration of the system, and
the secadmin role, used for configuring the security policy to be
enforced on the system.
Capability sets are a formal representation for the privileges that
may be enabled during the lifetime of a subject process and the
privileges that the subject may retain across a call to exec(2).
Every subject process has a capability state <B,I,P,E>, where B =
bounding set, an upper limit imposed on the capabilities in the other
three sets, I = inheritable set, the capabilities the subject may
retain across a call to exec(2), P = permitted set, an upper limit on
the capabilities that may be enabled in the effective set, and E =
effective set, the capabilities that determine the subject's current
privileges.
Associated with each object are five optional capability sets. The
first is the required capability set, which specifies the
capabilities a subject process must have in its effective set to
access the object. The other four capability sets are used by the
system to initialize the capability state of a process after it
performs an exec(2) on an executable object: B = bounding set, an
upper limit imposed on the bounding set of the new process, I =
inheritable set, an upper limit on the capabilities inherited into
the permitted set from the invoker's permitted set, P = permitted
set, the capabilities to be added to the permitted set, and E =
effective set, the capabilities to include in the new process'
effective capability set, subject to limitations imposed by the
invoker's capability state, and the object's bounding set,
inheritable set and permitted set.
Of particular importance is the way the system computes the
capability sets of a subject after it has performed an exec(2) on an
executable object. Let <Bs,Is,Ps,Es> denote the initial subject
capability state, and let <Bo,Io,Po,Eo> be the equivalent capability
sets for the executable object. Then the capability state of the new
executable image, <B,I,P,E> is computed from the subject and object
capability sets and the subject Set Effective Attribute (SEA) flag,
as follows:
B = Bs [ / Bo ]
I = Is / B
P = ( ( Is [ X Po ] ) [ / Io ] ) / B
/ P, Eo empty and SEA set.
E = -< NULL, Eo empty and SEA not set.
\ P / Eo, Eo non-empty.
where the slash (/) denotes set intersection, an X denotes set union,
and operations enclosed in brackets are performed only if the set
referenced is non-empty.
Capability Access Control (CAC) Policy
A discretionary access policy that allows the owner of an object to
specify the capabilities that a subject must have to access the data
contained in the object. CAC is not applied to accesses to an
object's attributes.
The system grants a subject CAC access to an object if and only if
the object's required capability set is a subset of the subject's
effective capability set.
A subject with appropriate privilege can read or modify an object's
required capability set via calls to dggetrequiredcap(2) and
dgsetrequiredcap(2). A subject with appropriate privilege can
read or modify a subject's current capability state via calls to
dggetcap(2) and dgsetcap(2). (See "Capability Mechanism", above.)
Discretionary Access Control (DAC) Policy
A policy that allows the owner of an object to control a subject's
access to the object by setting the object's access control list
(ACL). The ACL is a set of flags that specify each subject's read,
write and execute/search access to an object for an arbitrary number
of users and groups. Each set of read, write and execute/search
flags is known as an ACL entry. A minimum ACL is identical to the
permission flags used to control file access on a standard DG/UX
System. It consists of the following ACL entries:
ACL_USER_OBJ:
Access permissions for the object's owner (processes in the
POSIX 1003.1 file owner class).
ACL_GROUP_OBJ:
Access permissions for the object's group owner.
ACL_OTHER_OBJ:
Default access permissions, for all users not covered by other
permission classes (processes in the POSIX 1003.1 file other
class).
An extended ACL contains at least one additional ACL entry of one of
the following types:
ACL_USER:
Access permissions for a specified user.
ACL_GROUP:
Access permissions for a specified group.
The extended ACL also has a special ACL entry known as an ACL mask:
ACL_MASK_OBJ:
The maximum access permissions that any member of the POSIX
1003.1 file group class can attain; it acts as a mask. The
three flags in this entry apply to the ACL_GROUP_OBJ,
ACL_USER, and ACL_GROUP permission classes.
When an object has an extended ACL, the ACL_MASK_OBJ permissions are
stored where the standard DG/UX group permissions would be stored,
and are displayed in place of the ACL_GROUP_OBJ permissions by the
ls(1) command. This is reasonable, since this entry displays the
maximum permissions that any member of the resource's permission
classes (including the permission classes of the extended ACL) can
have.
The system determines DAC access to an object's information as
follows: (1) If the subject's effective UID matches the ACL_USER_OBJ
entry or one of the ACL_USER entries, then the system makes the
access decision by looking at the appropriate flag in that entry.
(2) If the subject's effective UID matches none of the ACL entries,
but its effective GID and/or one of its supplementary GIDs matches
the ACL_GROUP_OBJ class and/or any of the ACL_GROUP entries, then the
system makes the access decision by performing the binary OR
operation on all of the matching entries, masking the result by
ACL_MASK_OBJ and looking at the appropriate flag. (3) If neither
the subject's effective UID, its effective GID nor any of its
supplementary GIDs matches any of the ACL entries, then the system
makes the access decision by looking at the appropriate flag in the
default ACL_OTHER_OBJ entry.
All subjects have DAC read access to the attributes of an object, but
only the object's owner has DAC write access. The ACL can be
accessed via getacl(1) or setacl(1).
Mandatory Access Control (MAC) Policy
A policy that the system uses to prevent unauthorized subjects from
accessing objects containing sensitive information.
The basis for MAC implementation is the MAC label, an attribute that
represents either the sensitivity of the information contained in an
object or the authorization of a subject to view sensitive
information. A MAC label has two parts: the hierarchy, which
identifies a sensitivity level, and a set of categories, which
identify zero or more non-hierarchical information categories. The
hierarchy is represented by an integer, and represents progressively
more restrictive sensitivity classifications, which can be compared
in the standard arithmetic sense (i.e., <, > or =). The categories
component is represented as a bitmap, and represents an area of
interest. A particular category is present in the label if and only
if the corresponding bit is turned on in the category component of
the label. MAC labels, their hierarchy components and their
categories components are referred to by aliases; e.g., "Secret" or
"Top Secret" for hierarchies, and "Personnel" or "Accounting" for
categories.
MAC labels can be compared using the concept of MAC label dominance,
a method for comparing two MAC labels A = <Ha,Ca> and B = <Hb,Cb>.
If Ha is equal to Hb and Ca is equal to Cb, then A is said to
equal B.
If Ha is greater than or equal to Hb and Ca is a superset of
Cb, then A is said to dominate B.
If Hb is greater than or equal to Ha and Cb is a superset of
Ca, then B dominates A.
If none of the above applies, then A and B are incomparable.
Note that A equals B only if A dominates B and B dominates A.
The system divides the set of MAC labels into three distinct regions,
based on the hierarchy component of the label. The Administrative
region contains information which should only ever be directly
accessible to administrators, such as the A&A database or audit
information. The User region contains user data and possibly
applications. The Virus Prevention region contains system
executables and data files which need to be generally readable, but
which need strong protection against modification.
The Virus Prevention region is further divided into three subregions:
the VP-3 region, which contains DG/UX executables and
libraries;
the VP-2 region, which contains DG/UX data;
the VP-1 region, which is reserved for 3rd-party data and
executables.
To reflect the different nature of these types of data, the MAC
policy enforced within each region is somewhat different.
A MAC range is a set of MAC labels, defined by an upper bound label
and a lower bound label, where the upper bound dominates the lower
bound and both labels lie in the same MAC region. The MAC range
consists of all MAC labels dominated by the upper bound and which in
turn dominate the lower bound. As a special case, the MAC range may
be the empty set, in which case the upper and lower bound labels are
undefined.
A MAC tuple is a set of three MAC ranges, with one MAC range in each
of the three MAC regions.
When MAC is configured, every subject has both a MAC label and a MAC
tuple. The system uses the subject's MAC label and MAC tuple to make
MAC access and access override decisions. The system uses the
subject's MAC label to make access control decisions in the MAC
region in which the label lies. If the subject's label is in the
Administrative region, access to the User and Virus Prevention
regions is based on the upper end of the subject tuple's range in
that region. If the subject's label is in the User region, the
subject has no access to the Administrative region, and access to the
Virus Prevention region is based on the upper end of the subject
tuple's Virus Prevention region range. The subject's label is not
permitted to be in the Virus Prevention region. The label used to
make an access decision in a given region will be referred to as the
subject's effective label in that region.
Every object has a MAC label and/or a MAC tuple. If the object has a
MAC label, the system uses the label to make MAC access decisions,
and the label is called a governing MAC label. Otherwise, the object
must have a MAC tuple, which is referred to as the governing MAC
tuple.
The way the system makes MAC access decisions depends upon the
governing MAC attribute of the object. Suppose the object has a MAC
label Lo, and the subject's effective MAC label in the same region as
Lo is Ls. If the subject has no effective label in this region, the
subject has no access to the object. Otherwise, the system
determines MAC access as follows:
read access
Granted if Ls dominates Lo.
write access
Granted if Ls equals Lo, except if Lo is in the Virus
Prevention region, where write access requires appropriate
privilege.
Suppose the object is governed by a MAC tuple To. If the tuple
contains no non-empty MAC ranges, then access is allowed only if the
subject has appropriate privilege. Otherwise, access is determined
as follows:
read access
Granted if the subject has MAC read access to the upper bound
of each non-empty MAC range in To, according to the rules
above.
write access
Granted if the subject has MAC write access to at least one
MAC label which is within To.
A subject has MAC read access to an object's attributes if and only
if it has MAC read access to the object's information.
SEE ALSO
getacl(1), getmac(1), dggetcap(2), acllibrary(3), caplibrary(3),
maclibrary(3), nseclibrary(3), appropriateprivilege(5),
capdefaults(5), dn6(6M), trustedpath(6M),
Licensed material--property of copyright holder(s)