Security

System protection
File protection
Process protection
Protection domains
Protection matrix
Security

System protection

Access to a computer's resources may need to be restricted to ``authorised'' people.

File protection

Users of files need some kind of protection mechanism for their files. Files may need to be protected for the following operations:

read
write (or rewrite)
execute
append
delete

Process protection

When a process runs, it uses memory. This may need to be protected against other processes for

read
write

The general mechanism for talking about this is protection domains. A process can run in a protection domain, and this then has access to all the objects (files, printers, memory, etc) in that protection domain.

Objects belong to one or more protection domains, and in each domain they give access rights.

Example

When the MSDOS ``command.com'' runs, it does so in a domain in which most files grant delete access.

The files IO.SYS and MSDOS.SYS do not have delete access in this domain, and so they cannot be deleted by the ``del'' command (which is part of command.com).

Similarly, the printer device PRN does not grant delete access in this domain, and it cannot be deleted. On the other hand, it does grant write access, and so you can copy a file to PRN to send it to the printer. This looks like:

  MYFILE.TXT: write, read, delete, ...
  PRN: write

Example

Unix protection domains are defined by who you are and what group you belong to i.e. your ``uid'' and ``gid''.

Given a particular <uid, gid> pair, a list can be made of all files that allow operations to be carried out on them. For example, all files can be read that have the `r' bit set for that uid, or the `g' bit set for that group, and the `r' bit set for other.

Every process that runs with that <uid, gid> value can access for reading that same set of files.

Example

Files that are readable by everyone belong to every protection domain for reading.

Example

Not all processes that you create have the same values. Unix has a ``setuid'' mode for processes. If a command with the `s' bit set is run, your uid changes to that of the command's owner while it runs.

For example, the memory /dev/kmem is not readable by you, because it contains all running processes (including those of others). The command ``ps'' (process status) needs access to this though. So it runs setuid to root, and root can read this file.

Protection matrix

If you plot the set of protection domains in one direction, the set of objects in another, and draw up the table with entries being the access granted, you have the protection matrix.

protection matrix

which says that file 1 can be read by domain 1, read or written by domain 2, etc.

There are storage problems, which would require use of a sparse matrix. There are update problems: every time an object is created or destroyed the table must be modified. The table itself must be a protected object.

Access control lists

If the table is stored by columns, then it may be attached to each object, so file 1 has column 1, etc. To determine access to an object, you first have to look at the list attached to the object, to see if the domain is in the list. This is called an access control list (ACL).

file 1: (domain 1, r), (domain 2, rw)
file 2: (domain 2, rwx)
file 3: (domain 2, r), (domain 3, wx)

The advantage of this system is that it is the object itself that grants access to a process, based on what it knows about the process. This system is used by Windows NT.

A disadvantage is that the size of each column may be large and also may change. If it has to be kept in the file system, how is it done? I don't know how NT does it.

Unix solves this by simplifying the model: store the uid, gid and file permission mode in the inode, and then use a simple algorithm to grant or deny permission. This is not as flexible as the full system (eg you cannot grant access to all of a group except one).

For example,

  file 1: rwx for uid 28, rw for gid 20

would allow ``rwx'' for those in domain <uid=28, gid=10>, but only ``rw'' for those in domain <uid=14, gid=20>.

Capability lists

In a distributed system such as a WAN, it may be impossible to keep a complete list of protection domains anywhere. An ACL cannot be used in this case. Instead, the table is stored by rows, where each row is called a capability list.

domain 1: (file 1, r)
domain 2: (file 1, rw), (file 2, rwx), (file 3, r)
domain 3: (file 3, wx)

Attached to each object is a token of some kind called a capability. The O/S enforces the policy that unless a process has the capability for an object, it cannot access it.

When an object is created, the capability is given to the creating process i.e. the capability is placed in the process' capability list. From now on the process (or anything else in its protection domain) can access the object.

A process can give a capability to another process. This then places it on the second processes' capability list, so that it can also access the object. This way access to an object can spread throughout the system without the object having to do anything.

Security

All of these systems are a waste of time if there is no way of enforcing security access.

Supervisor mode

User processes run in their own address space, and have access to certain services. However, they should not be able to read or write system tables, boot sectors, etc. Something has to be able to do so, though, otherwise these tables would be read-only.

For example, there may be a table of processes currently executing in the system. For a new process to start, this must be writable. It must not be writable by everybody, or I could remove all your processes and vice versa.

Certain ``kernel'' tasks must be performed in ``supervisor'' mode. In this mode there may be need to access more than the user space. There may need to be hardware support for this such as the supervisor mode of the 68000.

supervisor mode

Passwords

Access to your own protection domain is usually through a password mechanism. In Unix, a process called ``getty'' waits for you to attempt to logon. When you do, it reads your password, encrypts it and compares it to the entry in the password file. If it matches, it creates a new process with <uid, gid> st to your domain and runs a login shell in that process.

Passwords should not be able to be decrypted. The Unix algorithm, for example, is one-way: it allows encryption only. To crack this system you have to encrypt all possibilities and test them against the actual encrypted passwords. Passwords should never be stored in plain text anywhere in the system.

Users have to co-operate with a password system. They should choose passwords that cannot be guessed. Guessable passwords include: your name; your partner's name; your dog's name; your birthday; your address; etc, etc.

The Internet worm tried all variations on these, plus words in the system-wide dictionary. It cracked over 20% of passwords this way.

Encryption

If data is important, it may need to be encrypted, especially if it is to be sent over a network. The DES encryption algorithm is common in the US, although it is illegal to export it. It is also suspected that the American Security Agencies are able to crack it. There are a number of ``public key'' encryption algorithms which are very secure. The PGP (Pretty Good Privacy) algorithm has a version that is legal to use in Australia. The comand is accessible on our system as ``pgp''. It allows encryption and digital signatures. Home