Security and the File System

File System Security

The problem addressed by the security system is how are information and resources protected from people. Issues include the contents of data files which are a privacy issus, and the use of resources, which is an accounting issue. Security must pervade the system, or the system is insecure, but the file system is a particularly good place to discuss security because its protection mechanisms are visible, and the things it protects are very concrete (for a computer system).

We're talking about some interesting stuff when we talk about security. For certain people who like puzzles, finding loopholes in security systems and understanding them to the point of breaking them is a challenge. I understand the lure of this. Remember, however, that everyone using these machines is a student like yourself who deserves the same respect that you do. Breaking into another person's files is like breaking into their home, and should not be taken lightly either by those breaking in, or those who catch them. Uninvited intrusions should be dealt with harshly (for example, it's a felony to break into a machine that stores medical records). If you really want to play around with UNIX(R) security, get yourself a linux box and play to your heart's content; don't break into someone's account here and start deleting files.

Policies and Mechanisms

Policies are real world statements about the protection that the system provides. These are all statements of (significantly different) policies:

• Users should not be able to read each other's mail
• No student should be able to see answer keys before they are made public
• All users should have access to all data.

The various systems in a computer system that control access to resources are the mechanisms that are used to implement a policy. A good secuirty system is one with clearly stated policy objectives that have been effectively translated into mechanisms.

The fact that data security does not stop with computer security cannot be understated. If your computer is perfectly secure, and an employee photocopies printouts of your new chip design, don't blame the computer security system.

Design Principles

Although every security system is different, some overriding principles make sense. Here is a list generated by Saltzer and Schroeder from their experience on MULTICS that remain valid today (these are fun to apply to caper movies - next time you watch Mission Impossible or Sneakers or War Games, try to spot the security flaws that let the intruders work their magic):

• Public Design Surprisingly public designs tend to be more secure than private ones. The reason is that the secuirty community as a while reviews them and reports flaws that can be fixed. Even if you take pains to keep the source code of your system secret, you should assume that attackers have access to your code. The bad guys will share knowledge, the good guys should, too.
• Default access is no access. This holds for subsystems just like login screens. It sounds like a platitude, but is a principle worth following at all levels. People who need a certain access will let you know about it quickly.
• Test for current authority Just because the user had the right to perform an operation a millisecond ago doesn't mean they can do it now. Test the authority every time so that revokation of that authority is meaningful.
• Give each entity the least privilege required for it to do its job. This may mean creating a bunch of fine-grained privilege levels. The more privilege an entity possesses the more costly a mistake or misuse of that entity is. Printer daemons that run as root can cause logins that run as root.
• Build in security from the start. Adding security later almost never works. There are too many holes to plug, and as a practical matter security is nearly impossible to add to a fundamentally insecure system.
• In order to make such a design integrable, it must be simple and capable of being applied uniformly.
• The system must be acceptable to the users. All security systems are a compromise between security and usability. The more features a system has, the more likely opportunities there are for exploitation. Furthermore, if a security feature is too onerous to the users, they will just invent ways to circumvent them. These circumventions are then available for the attackers. An unacceptable security system is automatically attacked from within.

A Sampling of Protection Mechanisms

The idea of protection domains originated with Multics and is a key one for understanding computer security. Imagine a matrix of all protection domains on one axis and all system resources (files) on another. The contents of each cell in the matrix is the operations permitted by a process (or thread) in that domain on that process.

While the pure domain model makes protection easy to understand, it is almost never implemented. Holding the domains as a matrix doesn't scale.

Some Domains and Rings

UNIX divides processes into 2 parts, a user part and a kernel part. When running as a user the process has limited abilities, and to access hardware, it has to trap into the kernel. The kernel can access all OS and hardware, and decides what it will do on a user's behalf based on credentials stored in the PCB.

This is a simplification of the MULTICS system of protection rings. Rather than 2 levels, MULTICS had a 64 ring system where each ring was more privileged than the ones surrounding it, and checked similar credentials before using its increased powers.

Access Control Lists

Another representation of the domain concept is Access Control Lists (ACLs). These are lists attached to each resource (file) that describe the valid operations on them. Generally the ACL languages are rich enough to describe users and groups of users economically. This economy comes from wildcarding and exclusion operators. Wildcarding provides a way to describe all users meeting a given criterion; exclusion operators allow exclusion of a set of users. Conceptually, though, each file contains a list of the users that can operate on the file.

The UNIX file protection system is similar, but simplified. There are 9 (really 12) bits associated with each file that determine the read, write and execution permissions of the of the owner, members of the owning group and everyone else. 2 of the other 3 bits allow limited domain switching. They are the setuid bits that allow processes running the program to change user or group id to be that of the owner of the file. When the owner of a file is root, this can convey considerable new power on the process.

ACLs are useful and support revokation of rights. That is when a user is reading the file, and the owner wants to stop that, the owner can remove that right. Because the system checks current authority (see above) the read will be stopped.

Capabilities

Another way to encode domain rights is to encode a processes rigths in its pointer to the object. For example file rights would be in the file descriptor; memory rights in a memory pointer. Such pointers with porotection information encoded in them are called capabilities.

Capabilities are kept in special lists (called C- lists) that must be protected from processes direct manipulation. One way is in hardware - the memory actually contains bits that the CPU cannot touch in suer mode that determine that a memory location holds a capability. Another is to make the C-list part of the PCB and only manipulable by the OS. A third is to have the OS encrypt the capabilities with a key unknown to the user.

Capabilities have operations defined on them, like copying, making copies with reduced or amplified rights. When the process presents the capability to the OS, the OS need not verify anything about the user, only whether the capability is valid.

That property makes it hard to revoke a capability, although there are a couple ways: embedded validity checks and indirect access..na