A Unifying Approach to the Design of a Secure Database Operating
Download
Report
Transcript A Unifying Approach to the Design of a Secure Database Operating
A Unifying Approach to the Design of
a Secure
Database Operating System
Written By:
David L. Spooner
Ehud Gudes
DATABASE MANAGEMENT SYSTEM
• Database:
a very
large, integrated collection of data.
• Models a real-world enterprise
– Entities (e.g., teams, games)
– Relationships
(e.g., The
Forty-Niners are playing in The Superbowl)
– More recently, also includes active components , often called
“business logic”. (e.g., the BCS ranking system)
• A Database Management System (DBMS) is a software system
designed to store, manage, and facilitate access to databases.
PROBLEM
•
Tuning of the DBMS to enhance performance of database applications is difficult
because of incompatible tuning of the OS.
•
The OS file system and access methods are often insufficient for a DBMS, forcing
the DBMS to implement its own extensions.
•
This in turn can lead to much duplication between the DBMS and OS. The DBMS is
often forced to rely completely on the OS for some aspects of security.
An Approach to Solving These
Problems
•
•
•
•
The ideas of McDonnell and Gagliardi are used in the design of the database
operating system proposed here.
The I/O and file support features of the DBMS and OS are integrated into one
unified I/O subsystem, eliminating the duplication. The primary responsibility of
this subsystem is physical I/O between main memory and secondary storage. Both
the DBMS and OS make use of this subsystem as needed.
Successful security systems demand that security enforcement be a central design
issue
Security enforcement mechanisms must be integrated with basic object
addressing mechanisms to produce a reliable and secure system design
Overall System Organization
Using the concept of subsystems, the design of the database operating system
becomes that shown in the Fig.
THE LOGICAL OBJECT MODEL
•
•
Definition of the Model
-To design a unified model for the DBMS/OS interface, one must have a model for
the stored information in the computer system.
-The information in the database to be structured into objects which can be
handled identically to the physical objects in OS.
A logical object type is defined recursively as:
1 ) a single attribute (simple);
2) a set of logical object types (structured);
3)a set of between m and n repetitions of a single logical object type.
THE SECURITY SUBSYSTEM
•
•
•
•
•
The design of the security subsystem for the database operating system was done
with the following functional requirements in mind.
- a user should be granted access to an object only if he requires access.
- Access control must be a function of the object type, subject, and operation.
- It must be possible to implement simple content-dependent security policy
where access to an object depends on the value of the object.
-A user process must have the ability to spawn independent sub processes with a
subset of the privileges of the parent process.
THE I/O SUBSYSTEM
> The I/0 subsystem, with the cooperation of the security sub-system, is
responsible for implementing the logical object operations.
> The retrieve operation is used to create a capability for a particular object.
> The access and the modify operations each require a capability for a
simple object as an argument, and are used to obtain or to change,
respectively, the value of the simple object addressed by the capability.
> The create and delete operations are used to create and delete
occurrences of the repeating object.
DESIGN ISSUES
>Performance is an important issue in the design of the database operating
system.
>Many design issues can significantly affect performance.
-- Preauthorization of object
>Another important design issue concerns aggregates of objects.In the
present definition of the security subsystem, every object ttype has an
access list, and every access to an object involves a capability. If the
granularity of objects is small, this involves a lot of overhead.
Conclusion
•
Flexibility of the Design
- The mechanism is provided to define and manipulate complex
structures of objects.
-Field level security policies are possible with access time checking
of rights
-There is no facility in the model to provide access control between
different modules within
one process.Access control is only available
between processes.
-The object model is not powerful enough to support data structure such as
linked list
Future Research
Many open problems and extensions to the design remain to be investigated.
There are many other important areas in the DBMS/OS which need to be
studied.
Currency control mechanism
Design Flexibility
References
[1] G. Andrews and J. McGraw, "Language features for process interaction," in Proc. ACM Conf.
Language Design for Reliable Software, 1977, pp. 114-127.
[2] .J. Arditi and E. Zakovsky, "An authorization mechanism for a database," in Databases:
Improving Usability and Responsiveness, 1978, pp. 193-213
[3]., "System R: Relational approach to database Pennsylvania State University, University Park,
management," ACM Trans. DataBase Syst., vol. 1, pp. 97-137, Pennsylvania State university, ,
June 1976
THANK YOU
QUESTIONS?????