Question

--What is the design principles for security? In particular, what are the principles of least privilege,
complete mediation, separation of privilege, and open design?
 What is an access control matrix?
 What are access control lists?
 What is the difference between discretionary access control (DAC) and mandatory access
control (MAC)?

Answer 1

Design Principles

The principles of secure design discussed in this section express common-sense applications of simplicity and restriction in terms of computing. We will discuss detailed applications of these principles throughout the remainder of Part 5, and in Part 8, "Practicum." However, we will mention examples here.

1 Principle of Least Privilege

This principle restricts how privileges are granted.

Definition

The principle of least privilege states that a subject should be given only those privileges that it needs in order to complete its task.

If a subject does not need an access right, the subject should not have that right. Furthermore, the function of the subject (as opposed to its identity) should control the assignment of rights. If a specific action requires that a subject's access rights be augmented, those extra rights should be relinquished immediately on completion of the action. This is the analogue of the "need to know" rule: if the subject does not need access to an object to perform its task, it should not have the right to access that object. More precisely, if a subject needs to append to an object, but not to alter the information already contained in the object, it should be given append rights and not write rights.

In practice, most systems do not have the granularity of privileges and permissions required to apply this principle precisely. The designers of security mechanisms then apply this principle as best they can. In such systems, the consequences of security problems are often more severe than the consequences for systems that adhere to this principle.

Example

The UNIX operating system does not apply access controls to the user root. That user can terminate any process and read, write, or delete any file. Thus, users who create backups can also delete files. The administrator account on Windows has the same powers.

This principle requires that processes should be confined to as small a protection domain as possible.

Example

A mail server accepts mail from the Internet and copies the messages into a spool directory; a local server will complete delivery. The mail server needs the rights to access the appropriate network port, to create files in the spool directory, and to alter those files (so it can copy the message into the file, rewrite the delivery address if needed, and add the appropriate "Received" lines). It should surrender the right to access the file as soon as it has finished writing the file into the spool directory, because it does not need to access that file again. The server should not be able to access any user's files, or any files other than its own configuration files.

13.2.2 Principle of Fail-Safe Defaults

This principle restricts how privileges are initialized when a subject or object is created.

Definition 13–2.

The principle of fail-safe defaults states that, unless a subject is given explicit access to an object, it should be denied access to that object.

This principle requires that the default access to an object is none. Whenever access, privileges, or some security-related attribute is not explicitly granted, it should be denied. Moreover, if the subject is unable to complete its action or task, it should undo those changes it made in the security state of the system before it terminates. This way, even if the program fails, the system is still safe.

Example

If the mail server is unable to create a file in the spool directory, it should close the network connection, issue an error message, and stop. It should not try to store the message elsewhere or to expand its privileges to save the message in another location, because an attacker could use that ability to overwrite other files or fill up other disks (a denial of service attack). The protections on the mail spool directory itself should allow create and write access only to the mail server and read and delete access only to the local server. No other user should have access to the directory.

In practice, most systems will allow an administrator access to the mail spool directory. By the principle of least privilege, that administrator should be able to access only the subjects and objects involved in mail queueing and delivery. As we have seen, this constraint minimizes the threats if that administrator's account is compromised. The mail system can be damaged or destroyed, but nothing else can be.

13.2.3 Principle of Economy of Mechanism

This principle simplifies the design and implementation of security mechanisms.

Definition

The principle of economy of mechanism states that security mechanisms should be as simple as possible.

If a design and implementation are simple, fewer possibilities exist for errors. The checking and testing process is less complex, because fewer components and cases need to be tested. Complex mechanisms often make assumptions about the system and environment in which they run. If these assumptions are incorrect, security problems may result.

Example

The ident protocol [861] sends the user name associated with a process that has a TCP connection to a remote host. A mechanism on host A that allows access based on the results of an ident protocol result makes the assumption that the originating host is trustworthy. If host B decides to attack host A, it can connect and then send any identity it chooses in response to the ident request. This is an example of a mechanism making an incorrect assumption about the environment (specifically, that host B can be trusted).

Interfaces to other modules are particularly suspect, because modules often make implicit assumptions about input or output parameters or the current system state; should any of these assumptions be wrong, the module's actions may produce unexpected, and erroneous, results. Interaction with external entities, such as other programs, systems, or humans, amplifies this problem.

Example

The finger protocol transmits information about a user or system [1072]. Many client implementations assume that the server's response is well-formed. However, if an attacker were to create a server that generated an infinite stream of characters, and a finger client were to connect to it, the client would print all the characters. As a result, log files and disks could be filled up, resulting in a denial of service attack on the querying host. This is an example of incorrect assumptions about the input to the client.

Design Principles We will be looking at eight principles for the design and implementation of security mechanisms. These principles draw on the ideas of simplicity and restriction. Simplicity makes designs and mechanisms easy to understand. Less can go wrong with simple designs. Minimizing the interaction of system components minimizes the number of sanity checks on data being transmitted from one component to another. Simplicity also reduces the potential for inconsistencies within a policy or set of policies. Restriction minimizes the power of an entity. The entity can access only information it needs. Entities can communicate with other entities only when necessary and in as few and narrow ways as possible. Communications is used in its widest possible sense, including that of imparting information by not communicating. Describe how the sendmail system works and some of the issues that could develop as a result of how it is designed. The eight design principles are: 1. Principle of Least Privilege A subject should be given only those privileges that it needs in order to complete its task. The function of a subject should control the assignment of rights, not the identity of the subject. This means that if your boss demands root access to a UNIX system that you administer, she should not be given that privilege unless she absolutely has a task that requires such level of access. If possible, the elevated rights of an identity individual should be removed as soon as those rights are no longer required. e.g. sudo su programs set uid only when needed 2. Principle of Fail-Safe Defaults Unless a subject is given explicit access to an object, it should be denied access to that object. This principle restricts how privileges are initialized when a subject or object is created. Basically, this principle is similar to the “Default Deny” principle that we talked about in the 6 dumbest ideas in computer security. Whenever access, privilege, or some other security related attribute is not granted, that attribute should be denied by default. 3. Principle of Economy of Mechanism Security mechanisms should be as simple as possible. This principle simplifies the design and implementation of security mechanisms. If the design and implementation are simple, fewer possibilities exist for errors. The checking and testing process is less complex. Interfaces between security modules are suspect area and should be as simple as possible. 4. Principle of Complete Mediation All accesses to objects should be checked to ensure that they are allowed. This principle restricts the caching of information, which often leads to simpler implementations of mechanisms. Every time that someone tries to access an object, the system should authenticate the privileges associated with that subject. What happens in most systems is that those privileges are cached away for later use. The subject’s privileges are authenticated once at the initial access. For subsequent accesses the system assumes that the same privileges are enforce for that subject and object. This may or may not be the case. The operating system should mediate all and every access to an object. e.g. DNS information is cached What if it is poisoned? 5. Principle of Open Design The security of a mechanism should not depend on the secrecy of its design or implementation. This principle suggests that complexity does not add security. This concept captures the term “security through obscurity”. This principle not only applies to cryptographic systems but also to other computer security related systems. e.g. DVD player & Content Scrambling System (CSS) protection 6. Principle of Separation of Privilege A system should not grant permission based on a single condition. This principle is restrictive because it limits access to system entities. The principle is similar to the separation of duty principle that we talked about in the integrity security policy unit. Thus before privilege is granted two or more checks should be performed. e.g. to su (change) to root two conditions must be met 1. the user must know the root password 2. the user must be in the right group (wheel) 7. Principle of Least Common Mechanism Mechanisms used to access resources should not be shared. This principle is also restrictive because it limits sharing of resources. Sharing resources provides a channel along which information can be transmitted. Hence, sharing should be minimized as much as possible. If the operating system provides support for virtual machines, the operating system will enforce this privilege automatically to some degree. 8. Principle of Psychological Acceptability Security mechanisms should not make the resource more difficult to access than if the security mechanism were not present. Do you believe this? This principle recognizes the human element in computer security. If security-related software or systems are too complicated to configure, maintain, or operate, the user will not employ the requisite security mechanisms. For example, if a password is rejected during a password change process, the password changing program should state why it was rejected rather than giving a cryptic error message. At the same time, programs should not impart unnecessary information that may lead to a compromise in security. In practice, the principle of psychological acceptability is interpreted to mean that the security mechanism may add some extra burden, but that burden must be both minimal and reasonable. e.g. When you enter a wrong password, the system should only tell you that the user id or password was wrong. It should not tell you that only the

Principle of Complete Mediation

This principle restricts the caching of information, which often leads to simpler implementations of mechanisms.

Definition

The principle of complete mediation requires that all accesses to objects be checked to ensure that they are allowed.

Whenever a subject attempts to read an object, the operating system should mediate the action. First, it determines if the subject is allowed to read the object. If so, it provides the resources for the read to occur. If the subject tries to read the object again, the system should check that the subject is still allowed to read the object. Most systems would not make the second check. They would cache the results of the first check and base the second access on the cached results.

Example

When a UNIX process tries to read a file, the operating system determines if the process is allowed to read the file. If so, the process receives a file descriptor encoding the allowed access. Whenever the process wants to read the file, it presents the file descriptor to the kernel. The kernel then allows the access.

If the owner of the file disallows the process permission to read the file after the file descriptor is issued, the kernel still allows access. This scheme violates the principle of complete mediation, because the second access is not checked. The cached value is used, resulting in the denial of access being ineffective.

Example

The Domain Name Service (DNS) caches information mapping host names into IP addresses. If an attacker is able to "poison" the cache by implanting records associating a bogus IP address with a name, one host will route connections to another host incorrectly. Section 14.6.1.2 discusses this in more detail.

13.2.5 Principle of Open Design

This principle suggests that complexity does not add security.

ACESS CONTROL MATRIX

An access matrix can be envisioned as a rectangular array of cells, with one row per subject and one column per object. The entry in a cell – that is, the entry for a particular subject-object pair – indicates the access mode that the subject is permitted to exercise on the object. Each column is equivalent to an access control list for the object; and each row is equivalent to an access profile for the subject

Access Control List (ACL)

DataSec, Essentials, Regulation & Compliance9.6k views

What Is an Access Control List

An access control list (ACL) contains rules that grant or deny access to certain digital environments. There are two types of ACLs:

• Filesystem ACLs━filter access to files and/or directories. Filesystem ACLs tell operating systems which users can access the system, and what privileges the users are allowed.
• Networking ACLs━filter access to the network. Networking ACLs tell routers and switches which type of traffic can access the network, and which activity is allowed.

Originally, ACLs were the only way to achieve firewall protection. Today, there are many types of firewalls and alternatives to ACLs. However, organizations continue to use ACLs in conjunction with technologies like virtual private networks (VPNs) that specify which traffic should be encrypted and transferred through a VPN tunnel.

Reasons to use an ACL:

• Traffic flow control
• Restricted network traffic for better network performance
• A level of security for network access specifying which areas of the server/network/service can be accessed by a user and which cannot
• Granular monitoring of the traffic exiting and entering the system

How ACL Works

A filesystem ACL is a table that informs a computer operating system of the access privileges a user has to a system object, including a single file or a file directory. Each object has a security property that connects it to its access control list. The list has an entry for every user with access rights to the system.

Typical privileges include the right to read a single file (or all the files) in a directory, to execute the file, or to write to the file or files. Operating systems that use an ACL include, for example, Microsoft Windows NT/2000, Novell’s Netware, Digital’s OpenVMS, and UNIX-based systems.

When a user requests an object in an ACL-based security model, the operating system studies the ACL for a relevant entry and sees whether the requested operation is permissible.

Networking ACLs are installed in routers or switches, where they act as traffic filters. Each networking ACL contains predefined rules that control which packets or routing updates are allowed or denied access to a network.

Routers and switches with ACLs work like packet filters that transfer or deny packets based on filtering criteria. As a Layer 3 device, a packet-filtering router uses rules to see if traffic should be permitted or denied access. It decides this based on source and destination IP addresses, destination port and source port, and the official procedure of the packet.

Types of Access Control Lists

Access control lists can be approached in relation to two main categories:

Standard ACL
An access-list that is developed solely using the source IP address. These access control lists allow or block the entire protocol suite. They don’t differentiate between IP traffic such as UDP, TCP, and HTTPS. They use numbers 1-99 or 1300-1999 so the router can recognize the address as the source IP address.

Extended ACL
An access-list that is widely used as it can differentiate IP traffic. It uses both source and destination IP addresses and port numbers to make sense of IP traffic. You can also specify which IP traffic should be allowed or denied. They use the numbers 100-199 and 2000-2699.

Linux ACL vs. Windows ACL

Linux provides the flexibility to make kernel modifications, which cannot be done with Windows. However, because you can make kernel modifications to Linux, you may need specialized expertise to maintain the production environment.

Windows offers the advantage of a stable platform, but it is not as flexible as Linux. In relation to application integration, Windows is easier than Linux.

A user can set access control mechanisms in a Windows box without adding software.

In terms of patching, Microsoft is the only source to issue Windows patches. With Linux, you can choose to wait until a commercial Linux provider releases a patch or you can go with an open-source entity for patches.

Discretionary Access Control

In discretionary access control (DAC), the owner of the object specifies which subjects can access the object. This model is called discretionary because the control of access is based on the discretion of the owner.

Most operating systems such as all Windows, Linux, and Macintosh and most flavors of Unix are based on DAC models.

In these operating systems, when you create a file, you decide what access privileges you want to give to other users; when they access your file, the operating system will make the access control decision based on the access privileges you created.

Mandatory Access Control

In mandatory access control (MAC), the system (and not the users) specifies which subjects can access specific data objects.

The MAC model is based on security labels. Subjects are given a security clearance (secret, top secret, confidential, etc.), and data objects are given a security classification (secret, top secret, confidential, etc.). The clearance and classification data are stored in the security labels, which are bound to the specific subjects and objects.

When the system is making an access control decision, it tries to match the clearance of the subject with the classification of the object. For example, if a user has a security clearance of secret, and he requests a data object with a security classification of top secret, then the user will be denied access because his clearance is lower than the classification of the object.

The MAC model is usually used in environments where confidentiality is of utmost importance, such as a military institution.

Examples of the MAC-based commercial systems are SE Linux and Trusted Solaris.