14 Securing DB2 and Implementing MLS on z/OS
information (such as top secret, sensitive, or unclassified), and also inherently
indicates to which non-hierarchical category the information belongs within that
level (such as project A, project B, or project C). The security administrator also
controls each subject’s access to an object or data within the multilevel secure
system by specifying which security labels the subject can use. A subject can
access information in an object only when the subject’s security label entitles the
access. If the subject’s security label does not have enough authority, the subject
cannot access the information in the object.
Mandatory access control is based on the theory of
dominance between security
labels. This dominance is based on each security label’s combination of security
level and zero or more categories.
2.3 Discretionary access control
DAC is the principle of restricting access to objects based on the identity of the
subject (the user or the group to which the user belongs). Discretionary access
control is implemented using
access control lists. A RACF resource profile
contains an access control list that identifies the users who can access the
resource and the authority (such as read or update) the user is allowed in
referencing the resource. The access control list overrides the universal access
list of the resource profile. The security administrator defines a profile for each
object (a resource or group of resources) and updates the access control list for
the profile. This type of control is
discretionary in the sense that subjects can
manipulate it, because the owner of a resource, in addition to the security
administrator, can identify who can access the resource and with what authority.
2.4 Security levels and security categories
Security labels establish an association between a RACF security level and a set
of zero or more RACF
security categories. For example, a system might have
three security levels, such as top secret, sensitive, and unclassified. It can have
various security categories that span these security levels and represent
individual projects or departments, for example, project A, project B, and
project C. Note the following definitions:
Security level This is controlled through a resource profile called
SECLEVEL in the RACF class SECDATA. It defines the
hierarchical degree of sensitivity of the data. The security
administrator defines in RACF each level, which consists of
a name and a numerical security level (the higher the
number, the higher the security level). In the previous
example, you might define top secret as level 30, sensitive
Chapter 2. Security labels 15
as level 20, and unclassified as level 10. The security
administrator can define up to 254 different levels, although
this is an impractical amount. We recommend keeping the
setup simple and concise.
Security category This is controlled through a resource profile called
CATEGORY in the RACF class SECDATA. It is
non-hierarchical and further qualifies the access capability.
The security administrator can define zero or more
categories that correspond to some grouping within an
organization that has similar security classifications.
Security label After defining the SECLEVEL and CATEGORY profiles, the
security administrator defines a resource profile in the class
SECLABEL for each security label. The security label is a
name of up to eight uppercase alphanumeric or national
characters. The national characters are $(X’5B’), #(X’7B’),
and @(X’7C’). The first character cannot be numeric. Each
security label name must be unique. Each SECLABEL
profile defines a combination of a SECLEVEL member and
zero or more members of the CATEGORY profile, which
are required for that particular security label. Note that you
do
not need to define a security label for every possible
combination of level and category.
Guideline: Although the system allows the definition of several thousand
categories, up to 254 security levels, and unlimited security labels, define
only
as many as you really need. A large number of levels and categories can
decrease performance, particularly at initial program load (IPL) time and for
the SETROPTS RACLIST(REFRESH) command. DB2 caches security labels
to avoid extra calls to RACF. The impact was measured and documented in
DB2 UDB for z/OS Version 8 Performance Topics, SG24-6465, Section 4.9,
“Row level security.” The caching works best if there are a relatively small
number of security labels to be checked compared with the number of rows
accessed in a long commit scope.

Get Securing DB2 and Implementing MLS on z/OS now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.