cis
...e discretion of the owner of an object, and those that are required to be used by the policy. Discretionary Access Control (DAC) With Discretionary Access Control the owner of an object is able to specify the types of access other users, or classes of users, can have to that object. Discretionary Access Control is a means of controlling access by subjects to objects. DAC is established by the owner of an object, and is changeable only by that owner. It is based on the identity of the subject and the identity of the object. Usually, the identity of the owner that the subject is an agent for is a significant factor in DAC. EXAMPLE: UNIX Permission Bits Binary Octal Comment 100 000 000 400 Read by owner. 010 000 000 200 Write by owner. 001 000 000 100 Execute (search) by owner. 000 100 000 040 Read by group. 000 010 000 020 Write by group. 000 001 000 010 Execute (search) by group. 000 000 100 004 Read by others. 000 000 010 002 Write by others. 000 000 001 001 Execute (search) by others. In UNIX, the owner of an object is permitted to set independently permissions as shown. There is a 9-bit field associated with every object, with the bits independently settable with the meaning in the table above. The Access Matrix Discretionary access controls can be captured in the access matrix. This is a (usually very sparse) matrix showing the totality of all subjects (users and processes) and their access permissions to a set of supposedly protected objects. An example is given in the following table. The permissions that are stored at each entry are drawn from the set rwaxdso. Capabilities A capability is an unforgivable permission that is incontestable proof of authorization for a subject to access an object. The capability is associated with a subject, is protected or otherwise given high integrity, includes the name of the object that it refers to, and specifies the access rights that the subject may have to the object. The set of all capabilities for a given subject is a row of the access matrix. If the access matrix were not so sparse, we might store the whole row with the subject and capture all the subject’s access rights at once. This is not practical because it takes too much memory. A capability-based system can in theory provide dynamically changeable domains for processes to run in. When a process (which is, of course, a subject) is started, it is given the capabilities it needs to do its thing. Dynamic domains are ideal for limiting the damage that a Trojan horse can cause. It is very difficult, however, to build such a system and make it efficient. A structure that attempts to do this is typically called a Least Privilege Mechanism (LPM). Subjects can have the right to pass on their capabilities to other subjects. Sometimes this right is conditional on, for instance, special access permission. Making this right conditional on ownership makes the system too secure – so secure that it can not be used for practical work. Because the right is not necessarily confined, it is difficult to make an effective list of all the subjects (users) who have access to a given object. This can make DAC impractical. For instance, one of the things that may be desirable is the ability of the owner of an object to revoke access by all other subjects. This is difficult if the permissions of each other subject has to be inspected. Most security systems require that an owner of an object be able to specify by name those other users who, either directly or indirectly through processes, are permitted access and those who are prohibited access. This usually must be achievable on the basis of user names. Grouping users is not considered fine enough control. It is hard to do this with capabilities – the control of passing on the capability becomes rather complicated. This is because capabilities are row-based mechanisms. Deletion of an object also presents a problem, because all access capabilities must be deleted as well. Profiles A profile is a row of the access matrix, with the empty entries deleted. It is, in effect, a summary of all a subject’s capabilities. It suffers from all the difficulties that capabilities suffer from, without some of their advantages. Access Control Lists Access control lists are the columns of the access matrix. It is usual to delete unnecessary entries, so that the list is not too large. An access control list is a list of the users who are permitted access to an object, and those who are prohibited access to the object. In this way, the control of access to the object is associated with the object, which is an intuitively satisfying concept. In most implementations, every file has associated with it another file called the ACL that ordinary users can not observe or alter. Observation of the ACL requires a special access privilege that only the trusted part of the system has and that can not be passed on. In order to limit the growth of the ACLs, a wild card mechanism is common. Let an ACL be composed of a sequence of entries of the form [user, group, permissions]. Let the (user) field be the name of a user. In practice this will be the name of the user who is accountable for the actions of a subject. Let the (group) field be the name of a group of users with a known membership. Both the (user) field and the (group) field can also be the single entry “*”. This * stands for any legitimate entry in the field it occupies, and is called a wild card. Let the permissions include the usual (rwaxdsop) set, or be the single entry (-). Then an access control list like the following one can be quite compact, and yet quite easy to search, to store, or to alter. Suppose the name of the file is SecretOfHeidi&Peter. When a file is created it will be given a default ACL, including something like ownership by the originating user with nobody having any access except him or her. The defaults may be system-wide, user specific, or associated with the directory that contains the file. All of these can coexist, but there are usually limits on the last two for obvious reasons. Another approach is to allow a user to specify that the ACL of a new file should mirror a given prototype ACL, perhaps the ACL of an existing file. Mandatory Access Control (MAC) Mandatory Access Controls (MAC) are means of restricting access to each object based on the sensitivity of the information contained in the object and on the authorization of each accessing subject. The sensitivity of the object is determined by its classification. The authorization of the subject is determined by its clearance. Every object has associated with it a label 6 containing its classification. Every subject has associated with it a label containing its clearance. Realms of Knowledge Not all knowledge is intended to be universal. Some knowledge is private for social reasons – medical records. Some knowledge is secret for functional reasons – when the next police drug-raid will happen. Some knowledge is more secret than other knowledge – the content of the next patent application to be filed by me contrasted with the content of the next paper to be published by you. Some of the difference, in the sense that this is more sensitive than that, is a matter of degree or of the identity of the observer. Some of the difference is related to the realm of knowledge that the information belongs to. Users need special permission to access information in special realms of knowledge. For instance, Patent Application is a realm of knowledge to which salesman has no access. A category is an attribute of an object that identifies it as belonging to some group of objects with some common basis – often a realm of knowledge. This basis usually has to do with the contents of the document. A category is a property of the data in the document. A caveat is an attribute of an object that also identifies it as belonging to some group of objects with some common basis. This basis usually has to do with what a user (a process) can do with the object. A caveat is usually a property of, or a restriction on, the way a document can be handled. A simple model is that a category is a property of the data and a caveat is a restriction on the handling of the data. If we have a secret research project with the category NuclearAutoEngine we might want to prohibit access by foreigners to some of the critical data. We do this with a caveat Foreigner. Any user with the entry Foreigner in his or her caveat list would be denied access. For simplicity, from this point on in this course the concept of the existence of a caveat will be ignored. The Dominates Relation and the Lattice Let there be a subject S and an object O. Let the clearance of S be a sensitivity level L(S). Let the classification of O be a sensitivity level L(O). The sensitivity levels are a totally ordered sequence, with the order relation being . Let the categories of S be a set G(S), and the categories of O be a set G(O) . The categories are a set. In comparing the categories of two objects the significant thing is whether one set of categories is a subset of the other set. Let the security level of S be L(S) , and the security level of O be L(O). The security level of an object or subject is the combination of its sensitivity and its categories. We are interested in being able to determine whether one subject or object is at a higher security level than another. We speak of this as one object dominating another if the first is at a higher level or the same level as the second8. In these notes dominates will be written using the symbol >. The converse of dominates, called is dominated by, is written <. The negatives of these two relations are sometimes useful; they are written > and < respectively. Let the two objects be and . , {S,O} and > [ L( ) L( ) ] and [ G( ) G( ) ]. The dominance relation defines a lattice on the possible security levels. A partial ordering like > or its inverse < defines a structure called a lattice. For subjects or objects a,b, c,L , the relation > has the following properties. Reflexive a > a is always true. Antisymmetric If a > b and b > a then L(a) L(b) and G(a) G(b) so that L(a) L(b) .Transitive a > b and b > c implies that a > c Common Attack Techniques There are only three ways into a computer system. The first bypasses all security mechanisms, and relies on a direct usage of the raw machine. Normally, this way is blocked because it must be done from the console of the machine, and hopefully that is in a locked room that Machiavelli himself could not enter from a distance. The second way concerns normal, authorized users. Normal users have every right to login to the machine. Once they are in, they can deploy any of the devices described below to circumvent the security controls. There is far, far greater security risk from authorized users than there is from any other person. The risk is because these users can legitimately pass the primary security perimeter, the login perimeter. Once it is passed, the threat comes from those who are careless, who want to play (often expressed as testing the security controls), or who are just plain evil. Third, a more covert entry relies on the stupidity of authorized users or system administrators. The primary security perimeter is the login perimeter. Entry is easy if this perimeter is not carefully guarded. For example, if the system permits it, an intruder can try to login using many (often thousands) of user names and corresponding passwords that are frequently used. The table above gives some hint to the kind of (name, password) pairs that might be on the list. There has been considerable work aimed at making passwords random, and memorable, and type able. Some aids exist9. Because of the world-wide computer network, the malicious invader need only login to one machine that is attached to the network. Then he or she can use its power to try to login to other machines. The first of these other machines that an evil invader will try to invade are those that have their names stored in the files of the machine that has been successfully invaded. These attempts can be in parallel, with the telephone bills being paid by the various machines’ budgets. Once a login to any machine is successful, the ability to repeat the login is made sureby one of the techniques below. Thus, the observation that by far is the most significant and important motto of the computer security professional: The most important security perimeter is the login perimeter. Trojan Horse Other than problems with the login perimeter, Trojan horses are the single most dangerous security problem. They have an additional serious disadvantage when compared to login. The act of performing a login can be recorded by the system, and many systems inform their users of the time and place of their last login. This can be monitored, and can sometimes show up either illegitimate users or misuse of passwords. On the other hand, Trojan horses operate entirely within the security perimeter. In practice they are only detected when they cause a serious breach of security, or by accident.A Trojan horse is a part of a program that otherwise conforms to the security policy. When this apparently innocuous program is executed it compromises the security of the user (or his agent executing it) by unauthorized violations of the security policy. Trojan Horses are built into the source code of a program by the original programmer, and have been known to be dormant for a period of time before any attempt is made to overcome security. The Trojan horse is the single most powerful tool in the armory of the malicious intruder. DAC is impotent against it. MAC protects against it, but only as long as the Trojan horse is confined to one realm of knowledge. The canonical example is as follows: Peter: “I really hate this editor. I wish there was a better one.” Heidi: “I wrote a pretty good editor last week. I think it is a great improvement. See – it uses changes in the background colour to highlight misspelled words. It has lots of other fancy features, too!” Peter: “That looks fantastic. Can I try it?” Heidi: [Gotcha] “Sure. It’s in my file /hack/myed. I will change the permissions so you can run it. I will appreciate any feedback you can give me!” The editor, when run by Peter in his directory /mysecret, does a wonderful job. It also contains a Trojan horse that copies all of the files from Peter’s directory /mysecret to Heidi’s directory /hack. There is no security mechanism to prevent this copying. It is all perfectly legitimate, because Peter is running the editor with his access permissions, and the editor is owned by Heidi and she has given it the right to write into /hack. Trojan horses are the operating mechanism behind a spoof and a virus and sometimes a worm. Trapdoor A trapdoor is a feature built into a program such that the provision of specific input data allows the process executing the program to overcome the security policy, usually by directly returning to the calling program with the called program’s permissions, completely bypassing all security guards. Trapdoors are built into the source code of a program by the original programmer, and have been known to be dormant for a period of time before any attempt is made to overcome security. Trapdoors and their establishment can be very sophisticated. Suppose there is a Trojan horse placed into the compiler such that • When it compiles the login procedure, it will generate unexpected (by the casual user) output code that will let the user path login without a password, and • When the compiler recompiles itself the code to build the Trojan horse into the compiler is itself always included in the compiler. The original source code for the Trojan horse can then be removed from the compiler, with the knowledge that the Trojan horse will always be included in the login procedure. The only way to detect this is to compare carefully the source and object code of the compiler, a task not frequently undertaken for obvious reasons. Spoofing A spoof is pretence that a subject is some other subject, or a user is some other user. It is possible only if the authentication mechanism fails, either because it is not good enough or because it contains a Trojan horse (e.g.: always authenticate the user path as the user root). There are several spoofs that are often overlooked. It is possible to be able to authenticate subjects to one another with adequate reliability. But how does the user, when he or she wants to login, tell that the software and hardware is what he or she expects it to be? How does the system software determine who it really is that is trying to login, and whether or not he or she is under duress? The answers to these kinds of questions are not obvious! Most secure computer criteria insist on a trusted path from a login location to the login procedure. There is no agreed best way to do this. Most system software identifies a potential user by some combination of: • Something he or she knows (a password). • Something he or she has (a key or badge). • Something he or she is (biometrics). • Where he or she is. • What time it is. Some users consider a login protocol that involves more than the first two of these factors to be a nuisance (or worse), and are actively hostile about their use. Virus A virus is a program that when executed operates entirely within the security policy. When a virus is activated (becomes part of a process) it uses a Trojan horse to search its authorized environment for executable programs that it is entitled to modify, and attaches itself to all such programs. In turn, when they are executed, the virus reactivates, and eventually spreads throughout the executable code in the computer. The only hard parts of setting up a virus are to substitute the entry point of the virus for that of the program, and then to pass the program’s parameters, supplied by the calling program as input to the original program, on to the original program when they appear at the entry to the virus. If this is done correctly the chance of a user detecting a virus is very nearly nil unless it announces its presence. The substitution of entry point can easily be done by renaming the original program with a name 11 unlikely to be noticed, renaming the virus with the original program’s name, and arranging that the virus knows about the renamed original program. Parameter passing just means that when the original program is called, the registers must be restored by the virus to their state that they had on entry to the virus. These programs are easy to create and very difficult to detect. The anti-virus agents in use today accomplish their task by looking for the distinctive patterns that are a representation of the virus’s code and looking for new copies of particular files. Worm A worm is a program that migrates from a computing environment to another computing environment, often keeping a record of the last few environments it has entered. The name worm comes from analogy with the animal well known to gardeners and fishermen, because each connected environment of the worm is called a segment. There are usually several segments in order to develop fault tolerance. Once the worm has migrated to a new environment, it can do whatever it is entitled to do according to its discretionary and mandatory access controls. A worm must have the ability to login to a target machine. It is this perimeter, as usual, that is the critical one.Good worms are used to distribute software, to propagate quick fixes to bugs, to modify system tables to reflect the present state (as when a new machine is added to a network) and ...