| Jones, A. and Liskov, B. A language extension for expressing constraints on data access. Communications of the ACM, 21(5):358-367, May 1978. |
....the users within the organization. A bank teller may have access to the deposit and withdraw methods whereas the bank manager may also have access to the method for setting the interest rate. This idea goes back as far as Jones and Liskov s suggestion of a static type based constraint mechanism [15] and has been adopted in contemporary middleware mechanisms. Java s RMI can be used in conjunction with a standard package for access control lists but it is up to the programmer to explicitly establish the relationship between the rights and the allowed method calls. The COM security mechanism ....
Jones, A. and Liskov, B. A language extension for expressing constraints on data access. Communications of the ACM, 21(5):358-367, May 1978.
....Paper object is revoked for the caller so that only one review may be submitted per reviewer. When submitting, reviewers receive new views that allow to retrieve other reviews for this paper. 4 Related Work Language approaches to protection have been know since the 1970s. An early approach is [JL78] which uses ADTs for enforcing protection. Here, however, schema Conference f callForPapers grants submitPaper on this to author; Member on this to reviewer; deadlineReached grants submitReview on Paper to reviewer; revokes submitPaper on this from author; makeDecision revokes ....
Anita Jones and Barbara Liskov. A language extension for expressing constraints on data access. Communications of the ACM, 21(5):358-367, May 1978.
....to our concept of shallow immutability. Access rights to objects via access control lists are discussed in [16] The idea is that each object has an owner (with full access rights) and access rights to certain operations can be given to named objects. As early as 1978, Jones and Liskov [8] (see also [17] discussed improving software quality by providing restricted access rights to objects. They introduced qualified types, where a base type is qualified with a list of allowed operations. Thus, Jones and Liskov do not see protection as a property of the reference but rather as a ....
....suggested schemes. Two approaches to the integrity of objects appear in the literature: 1) Guarantee that there are no references from the outside to the subobjects [1, 2, 6, 7] and (2) allow outside references and define explicitly what methods can be applied via each such outside reference [4, 8, 16]. In our opinion, the approach (1) is too strict whereas (2) is too fine grained. Our solution defines a concise yet powerful set of protection levels. An independent issue is implementation of protection against outside references. The protection is implemented by attaching it to the static type ....
[Article contains additional citation context not shown here]
A. Jones and B. Liskov. A Language Extension for Expressing Constraints on Data Access. Communication of the ACM, 21(5), May 1978.
....constructs. Recent work on Java [GJS96] has popularized the idea that languages are relevant to security, but the relation between languages and security is much older. In particular, objects and types have long been used for protection against incompetence and malice, at least since the 1970s [Mor73, LS76, JL78]. In the realm of distributed systems, programming languages (or their libraries) have sometimes provided abstractions for communication on secure channels of the kind implemented with cryptography [Bir85, WABL94, vDABW96, WRW96, Sun97b] Security depends not only on the design of clear and ....
Anita K. Jones and Barbara H. Liskov. A language extension for expressing constraints on data access. Communications of the ACM, 21(5):358--367, May 1978.
....some approximation of the originator controlled release labeling used by the U.S. DoD Intelligence community, although the ORAC model is dynamically checked. Static analysis of security guarantees also has a long history. It has been applied to information flow [DD77, AR80] to access control [JL78, RSC92], and to integrated models [Sto81] There has recently been more interest in provablysecure programming languages, treating information flow checks in the domain of type checking. Some of this work has focused on formally characterizing existing information flow and integrity models [PO95, VSI96, ....
Anita K. Jones and Barbara Liskov. A language extension for expressing constraints on data access. Comm. of the ACM, 21(5):358--367, May 1978.
....inside a Java class has access to the private fields of objects of that class, while methods defined outside the class cannot access these private fields. One can design safe languages that have more sophisticated access control features than the features above. For instance, Jones and Liskov [JL78] extended a language s type system to talk about access rights directly, to provide a similar functionality to advanced capability systems such as Hydra [WLH81] Recently Myers and Liskov [ML97] have extended this idea to cover information flow control. Another possible feature would be direct ....
A. K. Jones and B. H. Liskov. A Language Extension for Expressing Constraints on Data Access. Communications of the ACM, Volume 21, Number 5, p. 358--367, May 1978.
....work has focused on dynamic enforcement, but there has been some earlier work on static enforcement of access control. Jones and Liskov defined a system for statically enforcing discretionary access control through a scheme of restricted types, in which some methods were marked as inaccessible [JL78] Their rules define a form of subtyping, with security guaranteed by the inability to cast downward in the type hierarchy dynamically. However, the lack of any capability for dynamically enforcing access control checks makes this scheme impractical. The CACL model of access control [RSC92] has a ....
Anita K. Jones and Barbara Liskov. A language extension for expressing constraints on data access. Comm. of the ACM, 21(5):358--367, May 1978.
....restrictions appears necessary so that granting principals could specify how often access rights may be used or for how long a granted view remains valid. 4 Related work Using type information for specifying ne grained object protection is, of course, not new. Language based approaches such as [11, 19], typically rely on an extended notion of type that allows to selectively hide some of an abstract data type s operations for access control. We are not, however, aware of approaches that establish a separate type concept for authorizations. Views are a well known concept in relational and ....
Jones, A., Liskov, B.: A language extension for expressing constraints on data access. Communications of the ACM, Vol. 21(5), May 1978, 358-367
....control mediation. Consider a Printable interface that contains only a print method. Type abstraction can enforce the access control that a domain only use the print method for an object of type Printable. Even if the object has more methods, the receiving domain does not see the other methods [20]. However, this control can be bypassed in dynamically typed languages like Java, where it is possible to downcast Printable to the object s concrete type. One can add additional checks that guarantee that the protection domain being handed a reference of type Printable does not possess the ....
....are visibility constraints that could be verified by the loader. In particular, the directives could be varied for each namespace. 6 Related Work Research into programming language based approaches to security was active in the 1970s. Liskov Jones introduced the notion of qualified typing [20]. In this approach, the declaration of a variable of type T in a program is qualified by the set of operations that can be executed on an object bound to that variable. For instance, List, faddg: v means that only the operation add may be invoked on an object of type List bound to v. This approach ....
A. Jones and B. Liskov. A language extension for expressing constraints on data access. Communications of the ACM, 21(5):358--367, May 1978.
....have proven to be a powerful and flexible access control mechanism which solve such problems as revocation of access and confinement [3] It is important to distinguish between capabilities, which are a dynamic access control mechanism, and other static access control schemes. Jones and Liskov [10] described an access control mechanism which is closely related to capabilities, but requires the static specification of the access required to an object. This could then be statically checked at compile time. We reject this as being too inflexible. For example, consider the development of an ....
Jones, A. K. and Liskov, B. "A Language Extension for Expressing Constraints on Data Access", Comm. A.C.M., vol 21, 5, pp. 358-367, 1978.
....static analysis. Because waivers are applied dynamically and mention specific data objects, they seem likely to have administrative and run time overheads. Static analysis of security guarantees also has a long history. It has been applied to information flow [DD77, AR80] and to access control [JL78, RSC92]. There has recently been more interest in provably secure programming languages, treating information flow checks in the domain of type checking. Some of this work has focused on formally characterizing existing information flow and integrity models [PO95, VSI96, Vol97] Smith and Volpano have ....
Anita K. Jones and Barbara Liskov. A language extension for expressing constraints on data access. Comm. of the ACM, 21(5):358--367, May 1978.
....Type checks may be performed at compile time or at run time, though compiletime checks are obviously preferred when applicable because they impose no run time overhead. Access control checks are usually performed at run time, although some access control checks may be performed at compile time [JL78, RSC92] In general, it seems that some access control checks must be performed dynamically in order to give the system sufficient flexibility. By contrast, fine grained information flow control is practical only with some static analysis, which may seem odd; after all, any check that can be ....
....that takes this approach. Our propagation of ownership information is also reminiscent of models of access control that merge ACLs at run time [MMN90] Static analysis of security guarantees also has a long history. It has been applied to information flow [DD77, AR80] and to access control [JL78, RSC92] There has recently been more interest in provably secure programming languages, treating information flow checks in the domain of type checking [VSI96, Vol97] Also, integrity constraints [Bib77] have been treated as type checking [PO95] We have avoided considering covert channels ....
Anita K. Jones and Barbara Liskov. A language extension for expressing constraints on data access. Comm. of the ACM, 21(5):358--367, May 1978.
....static analysis. Because waivers are applied dynamically and mention specific data objects, they seem likely to have administrative and run time overheads. Static analysis of security guarantees also has a long history. It has been applied to information flow [DD77, AR80] and to access control [JL78, RSC92]. There has recently been more interest in provably secure programming languages, treating information flow checks in the domain of type checking. Some of this work has focused on formally characterizing existing information flow and integrity models [PO95, VSI96, Vol97] Smith and Volpano have ....
Anita K. Jones and Barbara Liskov. A language extension for expressing constraints on data access. Comm. of the ACM, 21(5):358--367, May 1978.
....Type checks may be performed at compile time or at run time, though compiletime checks are obviously preferred when applicable because they impose no run time overhead. Access control checks are usually performed at run time, although some access control checks may be performed at compile time [JL78, RSC92] In general, it seems that some access control checks must be performed dynamically in order to give the system sufficient flexibility. By contrast, fine grained information flow control is practical only with some static analysis, which may seem odd; after all, any check that can be ....
....that takes this approach. Our propagation of ownership information is also reminiscent of models of access control that merge ACLs at run time [MMN90] Static analysis of security guarantees also has a long history. It has been applied to information flow [DD77, AR80] and to access control [JL78, RSC92] There has recently been more interest in provably secure programming languages, treating information flow checks in the domain of type checking [VSI96, Vol97] Also, integrity constraints [Bib77] have been treated as type checking [PO95] We have avoided considering covert channels ....
Anita K. Jones and Barbara Liskov. A language extension for expressing constraints on data access. Comm. of the ACM, 21(5):358--367, May 1978.
....and in this procedure it would be legal to insert a rhinoceros object into the set, since a rhinoceros is a mammal. But the result is that our set of elephants now contains a rhinoceros (It s interesting to note that this problem was first pointed out in 1978 in the context of access control [JL78] Another curious point is that sometimes the subtype relation goes in the opposite way: ffl P[T] P[S] when S T This relation makes sense whenever P is an outputonly abstraction, such as an output stream. The relationship is ruled out, however, for any type with a method that returns an ....
Anita K. Jones and Barbara Liskov. A language extension for expressing constraints on data access. CACM, 21(5):358--367, May 1978.
No context found.
Jones, A. and Liskov, B. A language extension for expressing constraints on data access. Communications of the ACM, 21(5):358-367, May 1978.
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