Operating System (2140702)

Security

OS security refers to specified steps or measures used to protect the OS from threats, viruses, worms, malware or remote hacker intrusions.

Access control list

• Most of domains have no access at all to most objects, so storing a very large, mostly empty, Access matrix is a waste of disk space.
• Two methods are practical; the first is storing the matrix by rows and the second method is storing the matrix by columns, and then storing only the nonempty elements.
• The two approaches are surprisingly different.
• The first technique consists of associating with each object an (ordered) list containing all the domains that may access the object, and how.
• This list is called the Access Control List or ACL.
• Here we see three processes A, b, and C, each belonging to a different domain. There are three files F1, F2, and F3.
• For simplicity, we will assume that each domain corresponds to exactly one user, in this case, users are A, B, and C.
• Often in the security literature, the users are called subjects or principals, to contrast them with the things owned, the objects, such us files.
• Each file has an ACL associated with it. File F1 has two entries in its ACL (separated by a semicolon).
• The first entry says that any process owned by user A may read and write the file. The second entry says that any process owned by user B may read the file.
• All other accesses by these users and all accesses by other users are forbidden.
• Note that the rights are granted by user, not by process.
• As far as the protection system goes, any process owned by user A can read and write file F1. It does not matter if there is one such process or 100 of them. It is the owner, not the process ID that matters.
• File F2 has three entries in its ACL: A, B, and C can all read the file, and in addition B can also write it.
• No other accesses are allowed, File F3 is apparently an executable program, since B and C can both read and execute it. B can also write it.
• Many systems support the concept of a group of users. Groups have names and can be included in ACLs.

• The other way of slicing up the matrix of Fig. 9-2 is by rows.
• When this method is used, associated with each process is a list of objects that may be accessed, along with an indication of which operations are permitted on each, in other words, its domain.
• This list is called a capability list or C-list and the individual items on it are called capabilities.
• A set of three processes and their capability lists is shown in below Fig.

• Each capability grants the owner certain rights on a certain object. In above figure, the process owned by user A can read files F1 and F2, for example.
• Usually, a capability consists of a file (or more generally, an object) identifier and a bitmap for the various rights. In a UNIX-like system, the file identifier would probably be the i-node number.
• Capability lists are themselves objects and may be pointed to from other capability lists, thus facilitating sharing of subdomains.
• It is fairly obvious that capability lists must be protected from user tampering.
• Three methods of protecting them are known.
• The first way requires a tagged architecture, a hardware design in which each memory word has an extra (or tag) bit that tells whether the word contains a capability or not.
• The tag bit is not used by arithmetic, comparison, or similar ordinary instructions and it can be modified only by programs running in kernel mode (i.e., the operating system).
• The second way is to keep the C-list inside the operating system. Capabilities are then referred to by their position in the capability list.
• The third way is to keep the C-list in user space, but manage the capabilities cryptographically so that users cannot tamper with them. This approach is particularly suited to distributed systems.
• In addition to the specific object-dependent rights, such as read and execute, capabilities (both kernel and cryptographically-protected) usually have generic rights which are applicable to all objects.
• Examples of generic rights are
  1. Copy capability: create a new capability for the same object.
  2. Copy object: create a duplicate object with a new capability.
  3. Remove capability: delete an entry from the C-list; object unaffected.
  4. Destroy object: permanently remove an object and a capability.
• A last remark worth making about capability systems is that revoking access to an object is quite difficult in the kernel-managed version.
• It is hard for the system t find all the outstanding capabilities for any object to take them back, since they may be stored in C-lists all over the disk.
• One approach is to have each capability point to an indirect object, rather than to the object itself.
• By having the indirect object point to the real object, the system can always break that connection, thus invalidating the capabilities.
• ACLs and capabilities have somewhat complementary properties.
• Capabilities are very efficient because if a process says “Open the file pointed to by capability 3,” no checking is needed.
• With ACLs, a (potentially long) search of the ACL may be needed.
• If groups are not supported, then granting everyone read access to a file requires enumerating all users in the ACL.
• Capabilities also allow a process to be encapsulated easily, whereas ACLs do not.
• On the other hand, ACLs allow selective revocation of rights, which capabilities do not.
• Finally, if an object is removed and the capabilities are not or the capabilities are removed and an object is not, problems arise. ACLs do not suffer from this problem.