J.H. Saltzer, "Protection and the Control of Information Sharing in Multics," Comm. ACM, July 1974, pp. 388-402.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....June 10, 1998 Abstract The Distributed Java Object System adds advanced naming, persistence, security, mobility, and load balancing features to Java s basic RMI communications package. Security is provided through a combination of capabilities [Dennis and Van Horn 1966] and ACLs [Saltzer 1974] that combines some of the best features of both. Objects are persistently stored through directories that provide a user readable and location transparent naming system. Through a check pointing system, active objects allow themselves to be moved by a distributed dynamic load balancing system ....

Jerome H. Saltzer. Protection and the Control of Information Sharing in Multics.

....cost of context switches could be reduced compared to present processors. This paper presents Legba, a new protection cache architecture, which is designed to reduce the granularity of protection, without limiting the processor s clock rate. Legba furthermore supports a protected procedure call [20,21] mechanism which allows a program to change its protection domain in a controlled manner without the need to enter the operating system (OS) kernel. This enables fast protected component invocation. The reminder of this paper is organised as follows. Section 2 presents related work, Section 3 ....

....the segment information they hold does not need to be aligned to any particular block size. Unlike PLB entries, the sidecars are not tagged with a protection domain ID, and thus need to be flushed on a context switch. The idea of protected procedure entry points goes back to Multics call gates [20], which were a transparent, secure mechanism for increasing a process s privileges. Similar mechanisms exist on the x86 [38] and Itanium [34] architectures. These are tied to the hierarchical privilege model supported by these architectures. The hierarchical model has proven to be inflexible, and, ....

Jerome H. Saltzer. Protection and the control of information sharing in Multics. Comm. ACM, 17:388--402, 1974.

....that sharing is obtrusive, does not fit the typical file sharing model, and vrite sharing is complicated by the fact that files must be FTPed or e mailed back to the ovner. Furthermore, FTP and e mail are usually not used in a secure manner. The sharing semantics of bFS are taken from Multics [14]. Nev ACL entries inherit the ACL of their parent directory vhen they are created. Subsequent changes to the parent s ACL do not affect any objects vithin the directory. There exists a user database in bFS vhere the certificate of all sharing parties are stored. This database assigns a unique user ....

Jerome H. Saltzer. Protection and the control of information sharing in multics. Communications of the A CM, (7):388-402, July 1974.

....append only) The motivation for LIDS is the inability of the classic UNIX model to provide ne grained access control, and the existence of a superuser . LIDS uses access control lists (ACL) to control access to hardware and resources. It also uses a combination of ACL s and capabilities (see [20] for more on capabilities) to grant access based on the program executing, the uid of the user, and the inheritance of the parent process. 9 The LIDS project also attempts to eliminate the need for a superuser the source of many problems in the UNIX environment. Its aim is to provide enough ....

Saltzer, J. Protection and the control of information sharing in multics. Communications of the ACM 17, 7 (July 1974), 388-402.

....must provide protection among different user processes and between all user processes and trusted supervisor code. In addition, operating systems should support flexible sharing of data to allow applications to co operate efficiently. The implementors of early architectures and operating systems [5, 26] believed the most natural solution to the protected sharing problem was to place each allocated region in a segment, which has the protection information. Although this provides fine grain permission control and flexible memory sharing, it is difficult to implement efficiently and is cumbersome ....

....breach. The main performance impact of permissions checking is the additional additional memory traffic caused by table lookups. This is quantified below in Section 4. 3. 8 Protected calls The memory protection structures of the permissions table and PLB are sufficient to implement call gates [26]. Call gates are generalizations of system calls, and provide an efficient mechanism for mutually distrustful protection domains to safely call each other s services. A subsystem exports a limited number of code entry points to client domains. Calls to these entry points cause a switch in ....

J. Saltzer. Protection and the control of information sharing in Multics. Comm. ACM 17, 7 (July 1974.

....higher level software is not willing to cope with a failure in lower level software In conventional, non layered software systems, a software bug or a random hardware failure in any part of the system will usually cause the system as a whole to fail. In layered operating systems, such as Multics [27], crashes at some level can affect only higher levels. Protocols are a special case, since there is no need for a failure in any layer to necessarily cause a failure in any other layer. For example, a failure in the terminal handling la;er of a remote virtual terminal protocol need not affect the ....

J. Saltzer. Protection and the Control of Information Sharing in Multics. Communications of the ACM (July 1974).

....often make it hard to see the underlying order. 1 Introduction People have been working on computer system security for at least 30 years. During this time there have been many intellectual successes. Notable among them are the subject object access matrix model [11] access control lists [17], multilevel security using information flow [6, 13] and the star property [3] public key cryptography [14] and cryptographic protocols [1] In spite of these successes, it seems fair to say that in an absolute sense, the security of the hundreds of millions of deployed computer systems is ....

Saltzer, Protection and the control of information sharing in Multics. Comm. ACM 17, 7 (July 1974), 388-402

....databases and middleware in such a way to make the security mechanisms as relatively independent and self contained components in the systems. Most of operating systems implement authorization logic in the security part of their kernels [9, 18, 19, 23, 25, 30, 31, 35, 42, 44, 45,48, 53, 54, 60, 64] There are also specialpurpose ad on security software packages that furnish authorization decisions for operating systems [9, 15, 16, 32] Abadi et al. 1] and Lampson et al. [39] developed a unified theory of authentication and access control in distributed systems. Practical ....

J. H. Saltzer, Protection and the Control of Information Sharing in Multics, Communications of the ACM, vol. 17(7), pp. 388-402, 1974.

.... are restrictions, they ought not to require authority (although they do require a run time check to determine whether a principal can act for another principal) We can use these relabelings to write useful procedures that run with minimal authority, observing the principle of least privilege [Sal74]. Providing these extensions also makes it easier to model desirable security policies. For example, suppose that a user wants to define security classes in a multi level fashion: his own personal unclassified, classified, and secret classes for protecting his data. With these extensions, these ....

J. H. Saltzer. Protection and the control of information sharing in Multics. Comm. of the ACM, 17(7):388--402, July 1974.

....Up policy is enforced. 2.4 Case Studies This chapter has so far covered the area of protection and security by considering principles, models, and mechanisms. The next section will illustrate how protection and security has been implemented in previous systems. 2.4. 1 Multics The Multics [DD68, Sal74] system was designed with an emphasis on protection and security. The design of the protection system followed five main principles: 1. Protection is based on access with the default being no access. 2. Every access to every object is checked. 3. The design is not secret, as security by ....

Jerome H. Saltzer. Protection and the control of information sharing in Multics. Communications of the ACM, 17:388--402, 1974.

....distinct resources to competing parties) temporal (scheduling competing processes to execute at a different time) logical (creating logical barrier to avoid interference) or cryptographic (encrypting sensitive information) 3.2. 1 Design Principles of a Secure System Saltzer and Schroeder [97, 98] list the following principles for the design of secure protection mechanisms: 1. Economy of mechanisms. The design of the protection mechanism should be small and simple. A small and simple mechanism can be carefully analyzed and validated. 2. Fail safe default. The default condition should be ....

Jerome H. Saltzer. Protection and the control of information sharing in Multics. Communications of the ACM, 17(7):388--402, July 1974.

.... are restrictions, they ought not to require authority (although they do require a run time check to determine whether a principal can act for another principal) We can use these relabeling to write useful procedures that run with minimal authority, observing the principle of least privilege [Sal74]. Providing these extensions also makes it easier to model desirable security policies. For example, suppose that a user wants to define security classes in a multi level fashion: his own personal , and classes for protecting his data. With these extensions, these three security classes can be ....

J. H. Saltzer. Protection and the control of information sharing in Multics. Comm. of the ACM, 17(7):388--402, July 1974.

.... Most operating systems implement authorization logic in the security part of their kernels [Benantar 1996, Curry 1992, DEC 1989, Gligor 1986, Grampp 1984, Heydon 1994, Hommes 1990, Karger 1991, Luckenbaugh 1986, McCauley 1979, McInerney 1999, Mullender 1990, Pfleeger 1989, Quarterman 1985, Saltzer 1974, Walker 1980] Among special purpose ad on security software packages, Computer Associates Access Control Facility 2 (CA ACF2) CA 1998a] and CA Top Secret [CA 1998b] as well as IBM s Resource Access Control Facility (RACF) Benantar 1996, IBM 1976] are the most known ones. RACF is a security ....

J. H. Saltzer, "Protection and the Control of Information Sharing in Multics, " Communications of the ACM, vol. 17(7), pp. 388-402, 1974.

....is identified as a desirable security goal. Sometimes access control and authenticity are listed separately as well. In any case, it is important to identify your program s overall security goals, no matter how you group those goals together, so that you ll know when you ve met them. Saltzer [1974] and later Saltzer and Schroeder [1975] list the following principles of the design of secure protection systems, which are still valid: Least privilege. Each user and program should operate using the fewest privileges possible. This principle limits the damage from an accident, error, or ....

Saltzer, J. July 1974. Protection and the Control of Information Sharing in MULTICS". Communications of the ACM. v17 n7. pp. 388-402.

....of numerous secure systems, we have compiled a list of fundamental design concepts that have generally proved effective as basic tenets of security design. Many of these ideas have been around for decades. For example, many of the basic ideas behind the Multics development are still appropriate [176], and are included below. The following list is in no particular order. Base protection on permission, not exclusion. This is just good common sense. A conservative design should be based on why objects should be accessed, not why they should not. The default situation should be lack of access. ....

....to a public key encryption system can have a major impact on the system design [30] and performance. The security relevant portions of the system must be small, simple to understand, and isolated, as far as this is possible. This was one of the lessons learned from the original Multics experience [176], where any of 300 modules, averaging 200 lines of code each, could compromise the security mechanisms The importance of this has been restated many times [198, 183] and is clearly the thrust of the security kernel approach to secure operating systems [2] Complex things are just more difficult ....

Saltzer, J. Protection and the control of information sharing in multics. Communications of the ACM 17, 7 (July 1974), 388--402.

....practical, most of which is relevant to this work. In particular, all of the work on cryptographic protocols [10] and on firewalls [1] is directly applicable to the development of Legion itself. Other work, such as that on the definition of access control models [4] on information flow policies [9] and on verification [7] will be more applicable to the development of MayI functions which we will lean on as we develop a number of base classes from which users may inherit policies. In the same vein we will lean on existing technologies such as Kerberos [5] RSAREF [8] Sesame [6] etc. We ....

J. H. Saltzer, "Protection and the Control of Information Sharing in Multics," Communications of the ACM, Vol 17, No 7, pp 388-402, July 1974.

....distinct resources to competing parties) temporal (scheduling competing processes to execute at a different time) logical (creating logical barrier to avoid interference) or cryptographic (encrypting sensitive information) 3.2. 1 Design Principles of a Secure System Saltzer and Schroeder [94, 95] list the following principles for the design of secure protection mechanisms: 1. Economy of mechanisms. The design of the protection mechanism should be small and simple. A small and simple mechanism can be carefully analyzed and validated. 2. Fail safe default. The default condition should be ....

Jerome H. Saltzer. Protection and the control of information sharing in multics. Communications of the ACM, 17(7):388--402, July 1974.

....with sufficient authority, using the declassification mechanism. However, because these relabelings are restrictions, it would be safe for any process to perform them regardless of its authority. Direct support for the relabelings is therefore consistent with the principle of least privilege [Sal74] since it avoids unnecessarily vesting excessive privilege in processes. Extending the label model with support for these relabelings also facilitates the modeling of some desirable security policies. For example, suppose that a user wants to define security classes in a multi level fashion: ....

J. H. Saltzer. Protection and the control of information sharing in Multics. Comm. of the ACM, 17(7):388--402, July 1974.

....can add and delete users from groups without concerning other users about these changes. Simpler systems typically allow access control only in terms of groups (e.g. 1] Even the more sophisticated systems with access controls at the level of individual users usually support groups (e.g. [2]) It is almost inevitable that protection groups in an organization will be related by lines of authority and responsibility. We say U is a (proper) subgroup of V or UaeV if every member of U is thereby automatically a member of V but not vice versa. Note that members of U are more privileged ....

Saltzer, J.H. "Protection and the Control of Information Sharing in MULTICS." Communications of ACM 17(7):388-402 (July 1974).

No context found.

J.H. Saltzer, "Protection and the Control of Information Sharing in Multics," Comm. ACM, July 1974, pp. 388-402.

No context found.

Jerome H. Saltzer. Protection and the control of information sharing in Multics. Comm. ACM, 17:388--402, 1974.

No context found.

Jerome H. Saltzer. Protection and the control of information sharing in Multics. Comm. ACM, 17:388--402, 1974.

No context found.

J. H. Saltzer, "Protection and the Control of Information Sharing in Multics", Proc. IEEE 63, #9, September 1974

No context found.

J. H. Saltzer. Protection and the control of information sharing in Multics. Communications of the ACM, 17(7):388--402, July 1974.

No context found.

J.H. Saltzer. Protection and the control of information sharing in Multics. Communications of the ACM, 17(7):388-402, July 1974.

First 50 documents

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC