Page 281 - DCAP103_Principle of operating system

Principles of Operating Systems

Notes Generating a list of access control policies is of limited value, since business objectives, tolerance
for risk, corporate culture, and the regulatory responsibilities that influence policy differ from
enterprise to enterprise, and even from organizational unit to organizational unit. The access
control policies within a hospital may pertain to privacy and competency (e.g., only doctors and
nurse practitioners may prescribe medication), and hospital policies will differ greatly from those
of a military system or a financial institution. Even within a specific business domain, policy
will differ from institution to institution. Furthermore, access control policies are dynamic in
nature, in that they are likely to change over time in reflection of ever-evolving business factors,
government regulations, and environmental conditions. There are several well-known access
control policies, which can be categorized as discretionary or non-discretionary. Typically,
discretionary access control policies are associated with identity-based access control, and non-
discretionary access controls are associated with rule-based controls (for example, mandatory
security policy).
8.3.3 Discretionary Access Control (DAC)

DAC leaves a certain amount of access control to the discretion of the object’s owner or anyone
else who is authorized to control the object’s access. For example, it is generally used to limit
a user’s access to a file; it is the owner of the file who controls other users’ accesses to the file.
Only those users specified by the owner may have some combination of read, write, execute,
and other permissions to the file. DAC policy tends to be very flexible and is widely used in
the commercial and government sectors. However, DAC is known to be inherently weak for
two reasons. First, granting read access is transitive; for example, when Ann grants Bob read
access to a file, nothing stops Bob from copying the contents of Ann’s file to an object that Bob
controls. Bob may now grant any other user access to the copy of Ann’s file without Ann’s
knowledge. Second, DAC policy is vulnerable to Trojan horse attacks. Because programs inherit
the identity of the invoking user, Bob may, for example, write a program for Ann that, on the
surface, performs some useful function, while at the same time destroys the contents of Ann’s
files. When investigating the problem, the audit files would indicate that Ann destroyed her
own files. Thus, formally, the drawbacks of DAC are as follows:
• Information can be copied from one object to another; therefore, there is no real assurance
on the flow of information in a system.
• No restrictions apply to the usage of information when the user has received it.
• The privileges for accessing objects are decided by the owner of the object, rather than
through a system-wide policy that reflects the organization’s security requirements.
ACLs and owner/group/other access control mechanisms are by far the most common
mechanism for implementing DAC policies. Other mechanisms, even though not designed with
DAC in mind, may have the capabilities to implement a DAC policy.

8.3.4 Non-Discretionary Access Control
In general, all access control policies other than DAC are grouped in the category of non-
discretionary access control (NDAC). As the name implies, policies in this category have rules
that are not established at the discretion of the user. Non-discretionary policies establish controls
that cannot be changed by users, but only through administrative action.
Separation of duty (SOD) policy can be used to enforce constraints on the assignment of users
to roles or tasks. An example of such a static constraint is the requirement that two roles to be
mutually exclusive; if one role requests expenditures and another approves them, the organization
may prohibit the same user from being assigned to both roles. So, membership in one role may
prevent the user from being a member of one or more other roles, depending on the SOD rules,
such as Work Flow and Role-Based Access Control (see the following sections). Another example
is a history-based SOD policy that regulates, for example, whether the same subject (role) can

274 LOVELY PROFESSIONAL UNIVERSITY