 |
Description  |
|
|
The present invention relates to security and integrity controls on
database objects in computer systems. More particularly, the present
invention relates to secure database management systems that allow stored
procedures to safely execute at sensitivity levels different than the
sensitivity level of a subject initiating execution of the stored
procedure.
BACKGROUND OF THE INVENTION
Defense and commercial entities often store sensitive information in
computer databases. Without adequate safeguards, an enemy or competitor
could read or even tamper with a database's sensitive information. Various
methods have been employed to protect data in databases from such
unauthorized access. For example, database users are typically required to
login with unique user IDs and passwords before accessing databases.
Further, users' login accounts are often configured with clearances or
"sensitivity levels" controlling the level at which the users may operate
within the database system. For example, some users may be able to operate
at a classified sensitivity level but not at secret or top secret. Still
further, some database management systems permit auditing of various
users, terminals, data objects, etc. Thus, suspicious activity can be
detected and traced through an audit trail. These and other features of
database management systems are described in "Sybase SQL Server,"
Reference Manual: Volumes 1 and 2 (Document ID 32401-01-1000) and in
"Building Applications for Secure SQL Server" (Document ID
36030-010-1000), both available from Sybase, Inc. 6475 Christie Avenue,
Emeryville, Calif. 94608. These documents are incorporated herein by
reference for all purposes in their entireties.
A security policy known as "discretionary access control" or "DAC" allows
designated database system administrators and/or owners (i.e., creators)
of database objects to grant and revoke access privileges to specific
users. More specifically, the owner or administrator grants specified
users permission to execute specified commands and to access specified
tables, views, and columns. This policy is "discretionary" because the
object owner or designated system administrator can grant and revoke
privileges at his or her discretion. Unfortunately, DAC has some notable
security holes such as the "Trojan Horse" problem. A user having
privileges for some objects but not others can create software (the Trojan
Horse) to change the status of or copy a restricted object to which he or
she does not have access. If someone having access to the restricted
object then runs the Trojan Horse software, the DAC security system is
circumvented.
Another security policy, known as "mandatory access control" or MAC, gives
"subjects" access to database objects on the basis of sensitivity labels
only. The concept of "subjects" and "objects" is central to a MAC policy.
A subject is an active entity, such as a user at a workstation or a
command that acts on behalf of the user. An object is a passive entity
that contains or receives information. Examples of objects include
database tables, rows, views, and procedures. Before any object is
accessed in a MAC system, the subject's sensitivity label is compared with
the object's sensitivity label to determine whether the subject is allowed
to access the object in the manner requested. If this comparison shows
that the subject does not have a clearance dominating that of the object,
read access is denied. Also, if the comparison shows that the object does
not have a label dominating that of the subject, write access is denied.
Because objects carry labels, the Trojan Horse security hole is closed in
a MAC implemented database management system.
Although MAC does provide a fairly secure database, it is rather inflexible
in that it greatly limits the range of objects that a user can access.
Typically, the user can never read any objects that they do not dominate.
Some database systems could benefit by allowing some users to access
certain MAC-inaccessible objects for limited purposes such as entering
unclassified information in a classified database table. MAC itself
provides no mechanism for granting such limited access. One prior
modification of MAC systems does grant users temporary blanket privileges
to write-up (with no limit) or write-down (with no limit). In these
systems, the user is given write privileges for every database level
between his or her own level and the system highest level (write-up) or
the system lowest level (write-down). Unfortunately, in most instances,
only limited write-up or write-down privileges are necessary. For example,
a user's label may be unclassified, while the label of the object he or
she needs to modify is classified. The prior art blanket write-up
privilege would allow the user to access not only the classified object,
but all other objects in the system, up to the system's highest
sensitivity level (e.g., top secret).
Thus, while MAC and DAC systems provide a fair degree of database security,
other more flexible systems would be desirable. Specifically, a security
system giving users carefully controlled access to objects having
sensitivities outside the users' reach of their own would be desirable.
SUMMARY OF THE INVENTION
The present invention provides flexible database management systems having
improved security for database objects. These objects may be passive
elements such as tables, rows, views, the databases themselves, etc., or
they may be executable items such as stored procedures or triggers. The
invention provides an assurance in the form of a "certification" that
certain types of objects such as stored procedures, triggers, and views
used to access sensitive objects can be safely executed by various
subjects. Certification indicates that (1) a security officer has
evaluated and certified the object, and (2) a certified object has not
undergone a defined security-relevant change since certification.
Certification is particularly important in the context of a "trusted"
stored procedure or a "trusted" stored trigger. Such "trusted" executable
objects may have the unique attribute of being able to execute at
sensitivity levels different from the subject's sensitivity level. Thus,
the subject may use a certified trusted stored procedure or trigger to
access objects having sensitivity levels that would prevent access in a
MAC system. Preferably, in the systems of this invention, the subject can
access such objects only through "certified" trusted procedures or
triggers. Further, the systems of the invention preferably include a
mechanism for detecting security-relevant changes in the certified object,
and thereafter denying execution of the object. Preferably, the mechanism
includes a step of changing the "certification state" of an object from
certified to "suspect." Suspect objects cannot execute, thereby preventing
subjects from accessing protected objects after a potential or actual
security breach has occurred.
Certification indicates that an object in a particular database meets
certain defined security criteria pertinent to that database. The security
criteria may vary from system to system and are ultimately set by the
database owners and administrators. One security criterion might be that
certified objects can not read objects above a certain sensitivity level.
Another security criterion might be that the certified object has only
minimal potential for damaging accessed objects, etc.
Objects capable of being certified (e.g., procedures, triggers, and views)
are always in one or another "certification state" that may be changed
according to prescribed procedures. The available certification states
include, at least, the states of "certified" and "suspect," and in
preferred embodiments include the state of uncertified. Suspect objects
will not execute or be accessible under any circumstances, while certified
stored procedures will always execute. Further, "trusted" stored
procedures--those procedures that can execute at levels different than
that of the subject executing them--will execute only if they are in the
certified state. The certification state of an object can be "explicitly"
changed by a security officer who has (1) reviewed the object, (2)
determined that its certification state should be changed, and (3)
initiated a procedure that internally changes the certification state as
desired. In addition, the certification state can change automatically or
"implicitly" from "certified" to "suspect" if a defined security-relevant
event occurs. One such defined security-relevant event may be deletion and
recreation of a table or view referenced by the certified object.
Referenced tables, views, and other referenced objects are those objects
read and/or written to during execution of a trusted stored procedure or
other executable object.
The trusted stored procedures of this invention contain two types of
sensitivity labels: (1) read and write sensitivity labels used during
execution, and (2) an access sensitivity label used to determine whether a
subject can initiate execution of the stored procedure. The second of
these, the access sensitivity label, is somewhat analogous to a
conventional MAC label associated with an object. If the subject's read
sensitivity label dominates the trusted stored procedure's access
sensitivity label, the subject is granted access to the procedure. The
read and write sensitivity labels used during execution of a trusted
stored procedure have no counterpart in standard MAC policies. If a
trusted stored procedure's read sensitivity label dominates a database
object's access sensitivity label, the trusted stored procedure can read
that object during execution. Similarity if a trusted stored procedure's
write sensitivity label is dominated by an object's access sensitivity
label, the trusted stored procedure can write to that object during
execution. A subject's sensitivity labels need not dominate the trusted
stored procedure's read and write labels in order for the trusted stored
procedure to execute. In fact, a trusted stored procedure may access
objects beyond the reach of the subject in normal operation. In preferred
embodiments, such access is available only in the controlled environment
of the certified trusted stored procedure so that the risk of a security
breach is minimized or eliminated.
A preferred method of permitting a subject to access an object in a
database in a computer system involves first initiating a task on behalf
of the subject. As is well-known, when a user is operating in a
multitasking environment (e.g., having a server and multiple clients), a
task is created on behalf of the user. In this invention, the task
initially contains the sensitivity label(s) of the user or subject. These
labels include, at least, a current read and a current write label
associated with the subject. When the subject attempts to execute a
certified trusted stored procedure accessing a database object, the server
first determines whether the subject's current read label dominates the
procedure's access sensitivity label. Also, the server determines whether
any objects referenced by the procedure have undergone a security-relevant
change that would suspect the procedure. If the subject's read label
dominates the procedure's access label, and the procedure is not suspect,
execution of the procedure is initiated. During this process, the task
adopts the sensitivity labels of the trusted stored procedure. Thereafter,
the steps of the procedure are performed, accessing any referenced objects
(assuming the task's current sensitivity labels allow access to the
object) and then the process exits. Upon exiting, the labels of the
trusted procedure are removed from the task and those present before
execution of the procedure (usually the subject's labels) are re-applied.
These and other features of the present invention will be presented in more
detail in the following specification of the invention and the several
figures.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a state diagram showing the certification states and the
permissible paths between these states in the security system of this
invention;
FIG. 2 is a process flow diagram of a preferred database security plan
employing the system of the present invention;
FIG. 3 is a process flow diagram of the principal steps employed in the
database security system of this invention;
FIG. 4 is a table detailing the execution and recompilation options for
certain executable objects of the present invention;
FIG. 5 is a block diagram of a client-server computer system used to
implement the security system of this invention;
FIG. 6 is a block diagram detailing the operating system and procedure
layers employed in the client-server computer system of FIG. 1;
FIG. 7 is a process flow diagram detailing the steps used to create a
stored procedure;
FIG. 8 is a process flow diagram detailing the steps employed to compile an
"execute stored procedure" statement;
FIG. 9 is a process flow diagram showing the main steps associated with
applying a trusted stored procedure's sensitivity labels to a subject's
task;
FIG. 10 is an illustration of a system catalog excerpt containing entries
for a trusted stored procedure, a table, and a view; and
FIG. 11 is a process flow diagram detailing the process of executing a
multistep stored procedure in accordance with the present invention.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
1. DEFINITIONS
The following terms are used in the instant specification. Their
definitions are provided to assist in understanding the preferred
embodiments described in the specification.
A "subject" is a user or a command executing on behalf of a user. The
subject generally acts on "objects" by reading them or writing to them. In
the databases of a preferred embodiment, the subject will have one or more
sensitivity labels defining which objects it can access.
An "object" is an entity having certain attributes and, in the context of
this invention, is stored in a database. Exemplary objects include
databases, tables, rows, views, stored procedures, rules, etc. Attributes
of some objects include columns and triggers. Objects are generally
passive in the sense that they are acted upon by a subject, but they may
be capable of performing actions when accessed by the subject. For
example, a subject may initiate execution of an object such as a stored
procedure, which is a read operation.
"Dominance" refers to a relationship between a subject and an object
specifying whether the subject can access the object. In a MAC policy, a
subject is permitted read access to an object when the subject "dominates"
the object. Conversely, a subject is permitted write access to an object
when the object dominates the subject. Generally, one item dominates
another when the dominating item's sensitivity level is at or above that
of the dominated item. In preferred embodiments, write access is granted
only if the subject's write sensitivity label is equal to the object's
access sensitivity label. In some embodiments, dominance is defined in
terms of both a sensitivity level and one or more categories. If the
subject's categories do not match the object's categories, access is
denied.
"Sensitivity labels" are attributes associated with objects and subjects
indicating a clearance level such as top secret, secret, confidential,
classified, unclassified, etc. Within a database management system, the
highest level will be referred to herein as "system high" and lowest level
will be referred to as "system low." By comparing the sensitivity labels
of a subject and an object, a database security system can determine
whether the subject should be granted or denied access to the object.
Those labels associated with objects and used to determine whether a
subject can access the object are referred to herein as "access
sensitivity labels." Those labels associated with subjects (or executing
objects) and used to determine whether read/write privileges should be
granted for a particular object are referred to herein as "read
sensitivity labels" or "write sensitivity labels" depending upon the
function of the subject. For some subjects (or executable objects), read
and write labels can be specified over a range defined by "boundary
sensitivity labels."
A "stored procedure" is a collection or encapsulation of statements,
routines, built in calls, or other stored procedure calls describing an
operation within a database. The statements comprising the procedure may
be written in a database language such as ANSI standard structured query
language "SQL" or other database language. Alternatively, the stored
procedure statements may be written in a host language such as COBOL, C,
PL/1, dBASE, INFORMIX 4GL, etc. The stored procedure code may be
performance optimized so that it executes more efficiently. In preferred
embodiments, the stored procedure automatically recompiles each time a
change occurs.
"Compile" refers to an operation that produces operating code containing
source statements. As used herein, "compilation" may include substeps such
as parsing, normalizing, preprocessing, plan building, and optimization.
A "task" is one of possibly many programs or processes simultaneously
running on the CPU of a computer system. Each task takes a percentage of
the CPU depending upon the demands it makes while running. Each time a
user logs on, a new task associated with the user is initiated and runs
until he or she logs out. While a user is logged on, his or her task will
store certain attributes such as his or her sensitivity label(s), etc. In
preferred embodiments of this invention, the task includes a "sequence
frame" containing information that may change within the context of a
procedure. Tasks are sometimes referred to as "processes" in the context
of UNIX and other operating systems.
A "system catalog" is a system table containing metadata (i.e., information
about data in the system). Preferably the metadata is provided in tuples
or rows for certain database objects. Each catalog row may include various
attributes of a database object such as its object name, internal ID,
owner, type (e.g., system table, user table, view, procedure, trigger,
referential constraint, etc.), creation date, and audit settings. In
addition, the catalogs of this invention preferably include an access
sensitivity of the object (e.g. confidential, top secret, etc.) and may
include up to five read and write sensitivity labels (for stored
procedures and triggers) including current read, current write, maximum
read, maximum write, and minimum write. Still further, certain views,
triggers, and stored procedures will have a certification state contained
within their tuples in the system catalog.
Security Officer--A database administrator, sometimes referred to as a
system security officer or "SSO," who plays a role in the security of a
database management system. He or she may have various administrative
roles such as setting up server login accounts, overseeing changes to
passwords, and managing the audit system. For the purposes of this
invention, two very significant roles of the SSO are (1) certifying
objects, and (2) configuring trusted stored procedures with sensitivity
labels. Other security roles may be shared with a "system administrator."
System administrator or "SA"--A database administrator who has various
administrative roles such as installing the server, managing disk storage,
diagnosing and reporting system problems, backing up and loading
databases, granting permissions to and ownership of database objects. In
addition, the system administrator can have some security related roles
such as creating and locking server login accounts.
2. OVERVIEW OF MULTI-LEVEL SECURE DATABASE
The present invention has many applications in the public and private
sectors. For example, an automotive parts retailer who maintains a
database listing stocked parts might wish to give some customers limited
access to the database in lieu of printing catalogs. Assume that each
automotive part in the database is given its own row divided into columns
containing information of varying sensitivity such as the part numbers,
list prices, performance specifications, suppliers, and the retailer's
costs. Assume further that the database is divided into two tables, a
first "unclassified" table accessible to all customers and a second
"secret" table inaccessible to most customers. The unclassified table
contains only part numbers, list prices, and performance specifications,
while the secret table contains suppliers and costs. The database owner
makes the unclassified information available to customers through an
"unclassified" view of the first table. The suppliers and costs
information are available in a different table labeled at "secret."
Some of the retailer's customers also supply some of his pans. To these
suppliers, the retailer sometimes grants the right to access more
sensitive information for the limited purpose of updating their price and
other supply information. When a supplier needs to update his or her
information in the secret table of his database, the retailer creates a
trusted stored procedure having (1) a "certified" certification state, (2)
a classified access sensitivity label, and (3) secret read and write
sensitivity labels. The suppliers are given classified sensitivity labels
so that they can initiate execution of the stored procedures. When a
supplier executes the stored procedure, he or she can access and update
the supplier and cost entries of the second table (through the "secret"
read and write sensitivity labels), as well as the unclassified
information in the first table. The suppliers can access this secret
information only through the certified trusted stored procedure.
If for some reason, either of the database tables are deleted and then
recreated under the same name--through a security breach for example--the
certification state of the trusted stored procedure will become "suspect"
and the stored procedure will no longer execute. This prevents the
supplier from using the trusted stored procedure to reclassify, upgrade,
or downgrade the information and ensures that the tables are the correct
ones.
As the above example illustrates, certain objects have certification
states. In preferred embodiments, an object may be in one of three
certification states: certified, uncertified, and suspect. All objects
(whether or not susceptible to certification) are created in the
uncertified state. Uncertified objects behave like any object in a
conventional database management system, such as those employing a MAC
and/or DAC policy. They may be executed, written to, read by, etc., as
appropriate, by a subject having the necessary privileges to access them.
In MAC processes, they have one sensitivity level that must be dominated
by a subjects' read sensitivity level for the subject to read them. If
they are executable, they execute at their single level.
Objects that are initially in the uncertified state may be converted to a
certified state. Once in the certified state, the object is guaranteed to
have met certain security criteria defined for the particular database
system in which they exist. Conversion of an object to the certified state
requires an SSO to (1) evaluate the object to ensure that it meets the
defined security criteria and (2) initiate an internal database procedure
to change the state of the object to certified. Further, certified objects
are guaranteed to have not changed in a defined security-relevant manner
in the time since the SSO certified them. Because certified objects have
an extra measure of security, they may be used in certain situations that
would otherwise pose significant security risks. Objects in a suspect
certification state, on the other hand, may present a security risk if
they are executed. Thus, the significant feature of suspect objects is
that they can not execute. If there is indeed a security risk associated
with execution of suspect object, this feature ameliorates the risk.
FIG. 1 shows the three certification states and the permissible paths
between them. The paths represent either (1) explicit state changes which
are initiated by the SSO, or (2) implicit state changes which are
performed automatically by the database management system in response to a
specific event. An object in the uncertified state 2 may be explicitly
converted to the suspect state 4 over path 8. Alternatively, the
uncertified object may be explicitly converted to the certified state 6
along path 12. On the other hand, a suspect object or a certified object
may be converted to an uncertified object by explicit changes along paths
8 and 12, respectively. The two headed arrows on paths 8 and 12 indicate
that the explicit certification changes can take place in either
direction. With respect to state changes between certified objects and
suspect objects, two paths are available: explicit change 10 and implicit
change 14. As can be seen, the explicit change 10 can proceed in either
direction, while implicit change 14 proceeds only from certified 6 to
suspect 4. Thus, an object can not become certified absent the SSO
specifically initiating the change. In fact, in preferred embodiments, any
state change except that converting a certified object to a suspect object
(i.e., path 14) can be accomplished only by the SSO initiating an explicit
change.
As noted, the implicit state change from certified to suspect may be
triggered by a defined security-relevant event that has occurred to the
certified object or some object that it references. In preferred
embodiments, the security-relevant events that lead to the an implicit
change of state from certified to suspect include deletion of a table or
view referenced by the certified object. This will prevent execution of an
object that references a table or view that has been deleted and then
replaced with a different table or view of the same name. When a new
referenced object is introduced in place of one that had been initially
referenced when the certified object was certified, the new referenced
object is given a different ID, which can be detected by the certified
object. Because certified objects of the present invention identify
referenced objects (or "base" objects) by an identification number rather
than a name, they can detect when a referenced object has been replaced.
This guarantees base object "instantiation integrity" or binding to
specific instances of the base objects with the certified object.
While deleting or replacing a referenced object will initiate a state
change of a certified object, simply modifying, adding, or deleting
information contained in a table preferably will not initiate an implicit
certification state change. Generally, it will be sufficiently safe if
standard MAC and DAC policies are employed to protect against unauthorized
modifications of referenced objects. Complete replacement of an object,
however, presents a bigger security risk.
When a user or subject logs on in a multitasking environment, he or she is
given a task. That task contains various pieces of information about the
user, and most importantly for this invention, the user's current
sensitivity label(s). These sensitivity labels are used to determine
whether the user (or command on behalf of the user within the task) has a
read or write label that allows access based on the sensitivity label of
an object that the user wishes to access. When the user's label dominates
the access sensitivity label of the object (in the sense defined for MAC),
the user's task is given read access to the object. In preferred
embodiments, the user's task will contain at least two and more preferably
as many as five sensitivity labels. These labels include his or her
current read ("curread"), current write ("curwrite"), maximum read
("maxread"), maximum write ("maxwrite"), and minimum write ("minwrite").
No minimum read level is specified because it is assumed that users can
read down to the lowest level in the system. "Single level users" of the
present invention will be given only a single nonadjustable value for both
the read and write label. "Multi-level users," on the other hand, are
given all five sensitivity labels. These users can specify their current
read and write labels within the range defined by the boundary labels
(maxread, maxwrite, and minwrite), but can not adjust their boundary
levels. Stored procedures contain an access sensitivity label that must be
dominated by the user's curread label in order for the user to execute the
stored procedure. If the stored procedure has at least some of the other
labels (curread, curwrite, maxread, maxwrite, and rainwrite), it is deemed
a trusted stored procedure. When a user executes a trusted stored
procedure, the labels of that procedure are applied to the user's task,
albeit temporarily. When the procedure is finished executing, the trusted
stored procedure's labels are replaced (in the task) with the user's
original labels.
FIG. 2 presents an overview of a preferred security system of the present
invention. The process begins at 15 and then a stored procedure is created
in a step 16. This involves partial compilation or "normalization" of the
SQL code for the stored procedure, as detailed in FIG. 7. After the stored
procedure has been created in step 16, the procedure is analyzed in a step
17 by an SSO to determine its security status (i.e. whether it should be
certified) and other pertinent information. Preferably, the SSO will
examine not only the stored procedure itself but the objects it
references. After the SSO has analyzed the stored procedure, he or she may
decide whether label changes are required in a step 18. For example if the
stored procedure needs to read a top secret object during execution, but
the procedure's maximum read level is currently secret, the SSO should
rec | | |
