Protection and Security

Protection -- mechanisms (not policies) used to keep controlled access to resources (e.g. files, data, cpu, semaphores).
Three Levels --- System, Management, Individual
Principle of Least Privilege

Security -- a measure of confidence in the ability of a system to maintain the intregrity of its resources and access to them.

Purposes of protection:

These problems have always existed, but since Internet, have become more acute.

Free software foundation: all software should be free (since making extra copies costs almost nothing). Do you agree?

Protection provides mechanisms to enforce policies. Sometimes mechanisms drive policy (an old problem with computer system, not limited to security policy).

OS must protect objects: CPU, files, etc. It is processes which act on objects. What can be done with an object depends on its type; security concerns depend on what can be done to/with object.

We want to be sure you can't (advertently or whatever) modify /etc/passwd file except in a very controlled fashion.

Access Domains

Conceptually have set of domains, objects, and access rights for each object in the domain.

We can represent an object and its access list as an ordered pair:
< obj, {list of access rights} >. So domain 1 may contain:

   < O1, { read, write } >
   < O3, { read, write, execute } >
   < O4, { read, write, delete } >
   < O5, { login } >
   < O6, { dialin } >
   < O7, { dialout, reset, reconfig } >
   .
   .
   .
   < On, { set, unset } >
Other domains will have other objects (possibly overlapping the above) in which each object has appropriate access rights.

In terms of designing a particular OS, decisions must be made as to what domains are defined.

Can be in terms of userids, processes, groups, procedures. Most commonly, each user has a separate domain. Advantage of domain assigned to a procedure is that whenever a program calls that procedure, the program acquires its access rights, and then uses them when the procedure returns.

Examples:

  1. MVS -- system runs in two modes, supported by hardware: user and superuser(supervisor). To breech security only required finding a way for a process to successfully shift from user to superuser mode without detection.

  2. UNIX -- one mechanism intended to provide controlled access is the use of "set uid". This is a flag associated with a file (shows up as an "s" rather than an "x" in the owner flags from ls. Check the mail program). Usually all access is determined according to the user id of the individual who started the process. So whatever permissions your userid has, any process you start will have -- unless its a set uid process.

    For these special processes, the process assumes the access rights of the owner of the file rather than the person running the process. So if a file is owned by "root" and has the set uid flag, then even if you run it, it runs as root. In UNIX, root, also called the super-user, has all access rights.

    Any command you run which must modify anything to which you do not have access will have set uid, normally as root. For example,

    mail must write in /var/spool/mail/ where is the recipient.
    yppasswd must change /etc/passwd so you can change your passwd.
    ping needs network access.
    submit must write into various directories.
    nethack writes into score file.
    lpr writes into spool file.

    You can give files set uid with the chmod command. But you must own the file to do this. So if you want to provide a tool which anyone can run, but when it runs, it acts like you are running it, then you can set uid on the file with chmod o+xs . Whoever runs it will look (to the OS while this command is running) like you. If you can change the contents a file owned which has set uid, then you have complete access to everything on the system (except for encrypted stuff). This is a commonly exploited hole in UNIX. As UNIX proliferates, many new sys admin types are unaware of how dangerous set uid files are.

    Question: what do you discover if you find files with permissions -rwsr-xr-x owned by root in response to typing ls -lR | grep "^-r.s" | more ?
    With permissions -rwsrwxrwx?

Access Matrix

A conceptual representation of access rights:
 +---------------------------------------------------------+
 |   \ obj |         |        |        |        |          |
 |dom \    |    F1   |   F2   |   F3   |  ptr A |  term A  |
 +---------+---------+--------+--------+--------+----------+
 |  D1     |  read   |  exec  |        |        |          |
 |  D2     |         |        |        | print  |read,write|
 |  D3     |         |        |        |        |          |
    .
    .
    .
Since the matrix will likely be sparse, can store columns (then have access lists by object) or by rows (then have permission lists by domain).

Common to combine: have access lists (used for first access to object), then, if access successful, add to capability list of process for future accesses of object.

Lock-key scheme: each object has one or more locks, domain. Basic protection mechanisms:

In the first, we restrict physical access to space which system. Widely used particularly in the military.

In the second, the best example is passwords. Problem is that passwords are often easily guessed (e.g., birth dates, maiden names, pet/children/car names, initials of common expressions). And too easily passed around. And too often written down. Some dial-in systems use a call-back mechanism: you dial-in, pass the password test, (the modems may also exchange some data which you don't know about) then the system hangs up and dials your number; the modems can exchange data again.

Tokens: badges, thumbprints, voice prints, signatures, vessels in retina.

Encryption

A widely used security mechanism is to encrypt data. Particularly appropriate for data moved over networks, such as electronic fund transfers

Generally have encryption algorithm, which uses a user supplied key to compute encrypted data.


                       General Encryption System


                 encrypt                         decrypt
              +-----------+                   +-----------+
              |           |    cipher.txt     |           |
 plain.txt -->| Algorithm |------------------>| Algorithm |--> plain.txt
              |           |                   |           |
              +-----------+                   +-----------+
                    ^                               ^
                    |                               |
                   Key                             Key


Key Systems:

   Symmetric --- Same key is used to encrypt and decrypt.

   Assymmetric --- different keys are used (public and private).

In UNIX, password file, /etc/passwd, is publicly readable and is used for a bunch of things (on networks it gets more complicated so that you can log onto any machine). It contains an encrypted form of your password. Then login program prompts you for your password, encrypts it, then looks in /etc/passwd for your user-id and compares the encryption with the password there. Since the same encryption is used, the strings should match. (I think is also uses your userid, so that two users with the same password will not produce the same encryption in /etc/passwd.)

A common system cracking tool, once you have found one userid/password so that you can get onto a system, is to run the crypt program, using the userids in /etc/passwd and all the words in /usr/dict/words (a file on all UNIX system, contains ~25,000 common words, used for spell checking) as passwords. This takes a LONG time, but if you're running on someone else's system, who cares?

If you're a sys admin type, you should check your password file like this -- other people are. Scripts to do this are widely available. And you should check for set uid files. We had someone in California check our files last year, but they had access to a dictionary of one of the widely used Indian (as in India) languages, I forget which one. They found a bunch of passwords. And reported them to us.

DES

Public Key

Firewall

(The bug found in the Pentium chip came from a faculty member at Mary Baldwin trying to factor some large primes.)

In the cold war era, the CIA stopped publication of some encryption research. It is not clear if they were genuinely worried about how good the proposed algorithms were or if they were trying to convince the Soviets to use them. Known as the briar patch defense: No! Not that! Don't use that!! It will ruin us. Please, no. (heh, heh, heh).

Federal government is concerned about the use of these technologies; can make it impossible to wiretap. As telephones go digital, this is perceived as a real problem. In process of providing a "clipper chip" for use in digital communications. This will enable wiretapping on court order. Much controversy here.

Threats

Trojan horse -- a program which appears to provide some useful service, but does something undesirable.
A common one is to write a program that clears a screen and then writes:
          Old Dominion University
          Department of Computer Science
          SunOS 4.1.3 (marigold)

          login:
then reads from the screen. It will then wait patiently for someone to type his/her userid, and echoes each character as it is typed, then types
          Password:
on the next line. This time it does not echo what is typed. After the user types a return, it types:
          Login incorrect.
then issues the logout system call. Of course after saving the userid and password.

Easier. If you have "." in your path (type echo $path to see) and you cd to a friends directory, if he/she has any files which are the same as system commands, then you will run that code rather than the system command. It might do interesting things.

Trap door -- often, system programmers leave shortcuts in code to reduce the irritation/delays/overhead that mere users must go through to get onto a system (it's human nature). These are undocumented and are often left in the code.

(somewhat similar are cookies: undocumented commands left in a system for the amusement of those in the know. To really be a cookie, it should be harmless, and only known by "those in the know". Mac systems will display a picture of its original developers if you know the key strokes.)

Worms -- worms are programs that spawn mechanisms to clobber a system.
The most famous is Robert Morris', a first year Cornell grad student. It almost brought down Internet in 1988. Morris designed a self-replicating program (which exploited well-know problems/opportunities with rsh, which allows easy access to other machines on a network without checking passwords, with debugging code often left running in sendmail, and with the lack of array range checking (a nice feature of C) in finger. See text for a more complete discussion.

Viruses -- similar to worms, but are (almost) completed limited to the PC, Mac world. Multiuser systems are seldom affected since by their nature they contain several security mechanisms which are lacking/inappropriate on single user systems. Are usually introduced by the owner of the PC or Mac downloading some code which contains a virus, though some vendors have also shipped blister-packed software with viruses. Sometimes these are whimsical, sometimes very destructive. Once the program containing them is started, it will copy fragments of its code into other executables, so that even if the offending program is removed, the virus remains and can keep replicating itself. If it contains a time delay (doesn't do anything to make its presence know for some time), then it can have been infected backups also. Often the boot sector of the main drive is infected. Most PCs come with viral detection programs which detect change in checksums of programs.

Evaluation of Protection Mechanisms

In general, real mechanisms must be evaluated in terms of:
security -- how effective is the mechanism?

flexibility -- how easily can the mechanism respond to change (system changes, user changes, change in individual user needs)?

efficiency -- how costly is the mechanism? what is the impact on system performance?

convenience -- what is the impact on the user community?


Index Previous Next

Copyright ©2015, G. Hill Price
Send comments to G. Hill Price