ASSIGNMENT

ON

SECURITY
IN
COMPUTING
Submitted by,
NITHISH GEORGE
S8 cse
Roll no: 37
SQL SECURITY

Structured Query Language (SQL) provides the GRANT and REVOKE data
definition constructs to extend or withhold privileges from entities that wish to
access database objects. Privileges can be applied to individual objects (object
privileges) or to an entire class of objects (system privileges). The SQL92 standard
defines the syntax for privilege manipulation. All vendors support variations on
this theme.

The GRANT and REVOKE statement syntax are shown in the following figure.

Complex collections of privileges can be bundled by using database roles.

Privileges can be granted to roles, and then the roles can be assigned to principals.
This process simplifies security management.

Views are a commonly used mechanism to implement security within databases. A

simple view can be built on top of the join of a collection of base tables, renaming
or removing columns, selecting a subset of the rows, or aggregating rows by
average, minimum, or maximum. Views are examples of the Façade pattern in the
Gang of Four book [GHJV95]. The Façade pattern’s definition, by default and as
is, does not qualify it as a security pattern. A Façade must be used in association
with data object privilege mechanisms, such as the GRANT and REVOKE
mechanisms of the previous section, before it can be said to enforce security. A
user must be granted access to the view but must have no access to the underlying
base tables.

The syntax of a view statement is shown in the following figure.

The view can slice the joined based table relation into horizontal slices by only
exposing some rows, or into vertical slices by only selecting some columns (or, it
can do both).
The predicate expression can be quite complex, and if ad-hoc query access to this
view is granted, we cannot anticipate all of the operations that the user might wish
to execute on the view. Views present a number of issues when used for security.

1. Views are used extensively to support data restriction for business logic
purposes, rather than security. The application’s database designer needs to
carefully separate view definitions based on whether they were created for
enforcing security policy or business rules. Updates to security policy have to be
reflected in view redefinition or the creation of additional views, independent of
the application’s feature set.

2. Some database vendors provide read only access through SELECT statements to
views because of the complexity of managing UPDATE, INSERT, and DELETE
queries. Modification of the view could add too many NULL values to the base
tables in undesirable ways. Note that the view cannot see certain columns, which
must nevertheless be populated in the base tables as a result of any updates to the
view.

3. Even if the database supports writing to views, the ability to modify more than
one base table might be restricted. Writes to views can especially create
administrative overhead in cases where multiple triggers are used to support
modifications to the base tables. Modification of some columns, such as the join
keys, might be forbidden. Thus data that the user can see and believes that he or
she has ‘write access to’ might not be modifiable. Oracle version 8.0 provides
updateable views using Instead-of triggers, defined on the view, that execute in
place of the data manipulation language (DML) statement that fired them. Instead-
of triggers implement a sane version of the update.

4. View-based security might require one view for each of the many access modes:
SELECT from one view, UPDATE to another, and DELETE from a third. This
situation creates security management complexity and a maintenance headache.

5. Views can create computational overheads. Views based on joining many tables
might have severe performance costs if several of the selective predicates in the
‘WHERE’ clause of a query cause a join to a single base table but are independent
of the other clauses. This situation is called a star join, and unless carefully
optimized, it can be expensive.

6. Access to the underlying base tables must be restricted so that the user cannot
bypass the view to directly access data hidden from the view.

7. Views can potentially overlap if defined over the same base tables. Users denied
access to data through one view can potentially gain access through another. MI

D- L EVE L ARCH I T ECTU R E

8. Views cannot express some security policy requirements that involve evaluation
of conditions that are unavailable to the database, such as information about the
user that might be part of their environment.
9. Views cannot implement complex security policy requirements that involve tens
of thousands of scenarios.

DISCRETIONARY ACCESS CONTROL based on granting and revoking

privileges

Discretionary access models are all descendants of Lampson’s access matrix

[Lam73], which organizes the security of a system into a two-dimensional matrix
of authorizations in which each subject-object pair corresponds to a set of allowed
access modes. The access modes in the matrix can be modified through commands.
Allowed access must satisfy consistency rules.

Discretionary access control governs the access of objects by subjects based on

ownership or delegation credentials provided by the subject. These models are
implicitly dynamic in that they allow users to grant and revoke privileges to other
users or entities.

Once access is granted, it can be transitively passed onto other entities either with
or without the knowledge of the owner or originator of the permissions.
Discretionary access control models enable subjects to transfer access rights for the
objects they own or inherit, or for which they have received “grantor” privileges.
Consider they are a simplified model restricted to having only two kinds of
entities, namely subjects and objects (setting aside roles for a moment). A subject
can have system-wide privileges tied to whom they own (identity-based rights) and
object-ownership privileges tied to the objects they own (ownership rights). In
such a model, users can grant rights in three manners:

 A subject that owns an object can permit another subject to access it;
 A subject that owns an object can transfer ownership to another subject or
 A subject can transfer all or part of its identity-based rights to another
subject thereby granting all its modes of access to the receiver.

The relationships are described in the following figure.

Discretionary access control is flexible, but the propagation of rights through the
system can be complex to track and can create paradoxes. If A grants B the “grant”
right (effectively sharing ownership) to an object and B in turn grants C “read”
permission, what happens when A revokes the “grant” privilege from B? Does C
still have “read” access to the object, or does the original revocation cascade
through the system, generating additional revocations? Alternatively, does the
security model reject A’s revocation request, requiring that B first revoke C’s
rights? Reasoning about properties such as safety is also complex in DAC models.

MANDATORY ACCESS CONTROL for multilevel security

Mandatory access control governs the access of objects by subjects by using a

classification hierarchy of labels. Every subject and object is assigned a label. All
access is based on comparisons of these labels and, in general, is statically
enforced. We say that access control is mandatory because the system centrally
enforces all decisions to permit a subject’s activities based on labels alone. Entities
have no say in the matter.

Exceptions to static enforcement occur in models that support dynamic labelling at

run time or in systems that assign multiple labels to subjects or objects and use an
arbitrator to make an allow/deny decision. This situation can complicate
management significantly and make analysis of properties such as safety difficult.
Other models extend the label hierarchy horizontally at each label level by adding
compartments, which represent categories of information at that level. Mandatory
access control centralizes the knowledge base used to make decisions, although
subjects and objects can negotiate access based on local information. Entities are
allowed to read objects with lower classifications and can write to objects only
with the same classification level.

MAC require the classifications of users and data values into security classes and
enforce the rules that prohibit flow of information from higher to lower security
levels. Typical security classes are top secret (TS), secret (S), confidential (C) and
unclassified (U), where TS is the highest level and U is the lowest.
TS>=S>=C>=U
The commonly used model for multilevel security known as Bell-LaPadula model
classifies each subject (user, account and program) and object (relation, tuple,
column, view, operation) into one of the security classifications TS, S, C or U. The
clearance (classification) of a subject S is referred as class (S) and the classification
of an object O as class (O). Two restrictions are enforced on data access based on
the subject/object classifications.

1. A subject S is not allowed to read access to an object O unless class (S)>=

class (O). This is known as the simple security property.
2. A subject S is not allowed to write an object O unless class (S) <=class (O).
This is known as the star property.

The first rule enforces that no subject can read an object whose security
classification is higher than the subject’s security clearance. The second rule
prohibits a subject from writing an object at a lower security classification than
the subject’s security clearance. Violation of this rule would allow information
to flow from higher to lower classifications. For e.g. a user (subject) with TS
clearance may make a copy of an object with classification TS and then write it
back as a new object with classification U, thus making it visible throughout the
system.

To incorporate multilevel security notions into the relational database model, it

is common to consider attribute values and tuples as data objects. Hence each
attribute A is associated with a classification attribute C in the schema and each
attribute value in a tuple is associated with a corresponding security
classification. In addition, in some models, a tuple classification attribute TC is
added to the relation attributes to provide a classification for each tuple as a
whole. Hence, a multilevel relation schema R with n attributes can be
represented as,
 R (A1, C1, A2, C2, ……………….An, Cn, TC)
Where each Ci represents the classification attribute associated with the
attribute Ai.

Apparent key: The apparent key of a multilevel relation is the set of attributes
that would have formed the primary key in a regular (singular - level) relation.

Filtering: The process of producing tuples at a lower classification level from a

single tuple of a relation stored at a higher classification level.

Polyinstantiation: It is the state at which several tuples can have the same
apparent key value but have different attribute values for users at different
classification levels.

Consider an e.g.

Assume that the Name attribute is the apparent key. Now consider a select
query ‘select * from Employee’

Employee

Figure 1

Case 1: A user with security clearance S would see the original relation as it is,
i.e.

Figure 2
Case 2: A user with security clearance C would see the relation as:

Figure 3

Case 3: A user with security clearance U would see the relation as:

Figure 4

Thus we see that filtering introduces null values for attribute values whose
security classifications are higher than the user’s security clearance.

The entity integrity rule for multilevel relations state that all attributes that are
members of the apparent key must not be null and must have the same security
classification within each individual tuple. In addition, all other attribute values
in the tuple must have a security classification greater than or equal to the
apparent key.
Suppose that a user with security clearance C tries to update the value of
‘JobPerformance’ of Smith to ‘Excellent’; the SQL statement would be
Update employee
Set JobPerformance = ‘Excellent’
Where Name = ‘Smith’

Since the view provided to users with security clearance C (fig 3) permits such
an update, the system should not reject it; otherwise the user could infer that
some non null value exists for the ‘JobPerformance’ attribute of Smith rather
than the null value that appears. This type of inference should not be permitted
in highly secure systems. The solution is to create a polyinstantiation for the
Smith tuple at the lower classification level C as shown below:

This is necessary since the new tuple cannot be filtered from the existing tuple
of classification S.

STATISTICAL DATABASE SECURITY

Statistical databases are used mainly to produce statistics on various

populations. A population is a set of tuples of a relation that satisfy some
selection condition. The database may contain confidential data, which should
be protected from user access. However, users are permitted to retrieve
statistical information on populations, such as sum, average, maximum,
minimum and standard deviation. i.e. statistical database users are not allowed
to retrieve individual data but are allowed to access statistical data as a whole.
Statistical database security techniques must prohibit the retrieval of individual
data. This can be controlled by prohibiting queries that retrieve attribute values
and by allowing only queries that involve statistical aggregate functions such as
COUNT, SUM, MIN, MAX, AVERAGE and STANDARD DEVIATION.
Such queries are called statistical queries.

In some cases it is possible to infer the values of individual tuples from a

sequence of statistical queries. As an example, consider the two statistical
queries:

Q1: select count (*) from person where <condition>;

Q2: select avg (income) from person where <condition>;

Suppose that we are trying to find the salary of ‘Jane Smith’ and we know that
she has a P.H.D. Degree and she lives in the city of Bellaire, Texas. We issue
query Q1 in the following condition: (Last_degree = ‘P.H.D.’ and Sex = ‘F’ and
City = ‘Bellaire’ and State = ‘Texas’). If we get a result of 1 for this query, we
can issue Q2 with the same condition and find the income of ‘Jane Smith’. Even
if the result Q1 on the preceding condition is not 1 but is a small number say 2
or 3, we can issue statistical queries using the functions MAX, MIN and
AVERAGE to identify the possible range of values for the income of ‘Jane
Smith’.

The possibility of inferring individual information from statistical queries is

reduced if no statistical queries are permitted whenever the number of tuples in
the population specified by the selection condition falls below some threshold.

Another technique for prohibiting retrieval of individual information is to

prohibit sequences of queries that refer repeatedly to the same population of
tuples.