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 don't want you to be able to send commands to dial our modems.
We want to be sure you can't (advertently or whatever) modify
/etc/passwd file except in a very controlled fashion.
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:
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,
/var/spool/mail/ where yppasswd must change /etc/passwd so you can change your passwd.
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?
+---------------------------------------------------------+
| \ 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.
Must be able to change access privileges. So
+---------+---------+--------+--------+--------+----------+------+------+------+
| \ obj | | | | | | | | |
|dom \ | F1 | F2 | F3 | ptr A | term A | D1 | D2 | D3 | ...
+---------+---------+--------+--------+--------+----------+------+------+------+
| D1 | read | exec | | | | |switch| | ...
| D2 | | | | print |read,write| | |switch| ...
| D3 | | | | | | | | | ...
.
.
.
Basic protection mechanisms:
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.
Generally have encryption algorithm, which uses a user supplied key to compute encrypted data.
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?
(What I`m doing here is controversial. Many UNIX system administrator types do not like such casual spreading of common UNIX weaknesses. I believe that it is dangerous to rely on ignorance as a basic security tool. Particularly with UNIX. Too widely used.
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.
public encryption key: ( e, n )
private key: ( d, n )
(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 error, 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.
Old Dominion University
Department of Computer Science
SunOS 4.1.3 (marigold)
login:
Password:
Login incorrect.
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.
Two war stories:
It helped not to catch a cold. And not to get pregnant. (To keep several people from slipping through together, as the staff was prone to due since this procedure is something of a nuisance, the weight of each person was looked up and the floor of the room was really a set of scales.)
Incidentally, recognition of a signed name by the system was based only on the pressure pattern (how hard you push down and when) and not on the physical appearance of the signature. Impossible (almost?) for forgers to fool because they are good at appearance. But once you know what it's checking, if you can experiment, then it is much easier to fool. But you have to understand what it's checking.
| Index | Previous | Next |
|---|
Copyright ©1998, G. Hill Price
Send comments to G. Hill Price