Role-Based Principals
Thomas Riechmann and J¨urgen Klein¨oder
University of Erlangen-Nuernberg, Dept. of Computer Science IV†, Martensstr. 1, D-91058 Erlangen, Germany
{riechman,kleinoeder}@informatik.uni-erlangen.de
http://www4.informatik.uni-erlangen.de/~{riechman,kleinoeder}‡ §
Abstract. Most current object-based distributed systems support ac-cess control lists for acac-cess control. However, it is difficult to determine which principal information to use for authentication of method calls. Domain-based and thread-based principals suffer from the problem of privileges being leaked. Malicious objects can trick privileged objects or threads to accidently use their privileges (UNIX s-bit problem). We introduce role-based principals to solve this problem. Each object refer-ence may be associated with a role, which determines trust, authentica-tion and permissible data flow via the reference. An object may act in different roles when interacting with different other parties. Exchanged references automatically inherit the role. By initially defining such roles, we can establish a security policy on a very high abstraction level. Our security model is based on meta objects: principal meta objects provide principal information for method invocation, access control meta objects implement access checks.
1
Introduction
The object-based programming paradigm has become more and more popular. Currently, it is conquering the world of distributed programming models. There are two basic paradigms for access control in such systems: Capabilities [2], [15], [6], [13], [8] and access control lists (ACLs). Capabilities is the most obvious one, because an object reference is per se a capability. The main disadvantage of capabilities is that it is hard to keep track of their distribution [5]. Thus it is hard to determine, who is able to access a specific object.
So most object-based systems additionally support ACLs. Examples are CORBA [9], DSOM [1], and Legion [16]. Based on principal information (user information, credentials) about a method call ACLs determine who has access † This work is supported by the Deutsche Forschungsgemeinschaft DFG Grant
Son-derforschungsbereich SFB 182, Project B2.
‡ This paper is published in: Proceedings of Third Australasian Conference on Infor-mation Security and Privacy (ACISP 98), Brisbane, Australia, 1998.
§ Due to copyright resrictions (Springer) this printout may not be copied or dis-tributed.
to a specific object. The principal is held responsible for the call. With ACLs it is easy to determine who has access to specific objects.
There are three common policies how to provide principal information [14]:
– Principal information is provided explicitly for each call. The caller has to decide for each call which principal information is used. As each object has to know about principals and about the security policy (e.g., which principal information it has to use for a specific method invocation), it is difficult to write reusable and well structured code. Security policy and application semantics are mixed.
– Principal information is bound to objects or groups of objects (e.g., do-mains). Examples are DSOM, Java, Legion, and Unix. An object uses the same principal information for every call it executes (object-group-based prin-cipals). This policy suffers from a reference-proxy problem: Objects have to take care that they are not misused as forwarder for method invocations of lower privileged objects (this is similar to the Unix s-bit problem.)
– Principals are bound to threads (e.g., Java-1.2 [12] uses a mixed domain / thread model). All invocations executed by a thread use the thread’s prin-cipal information. Systems with this policy have to cope with the callback problem: A privileged thread has to be very careful which methods of which objects it calls, because the target object can use all of the thread’s privi-leges. It may have to drop privileges before it calls untrusted methods. Even with mandatory policies, such as role-based access control [3], this problem occurs1.
In this paper, we introduce a new security paradigm which eliminates these problems. Our mechanism allows us configuration of principal information for method invocations on a per-reference basis. For method invocations via different references an object may use different principal information and thus authorize itself differently depending on the current situation and the target reference. Fig. 1 shows a system-administration application with high privileges for access to the system’s password database. It does not need these privileges for printing. With role-based principals we can define two roles with different principal in-formation, which are used in these two different situations. For different purposes the system-administration application may even access the printer in different roles: with high privileges for printer administration and with standard user privileges for printing.
The basic concept for these mechanisms is the Security Meta Object (SMO). Such an SMO can be attached to an object reference. Then it has control over all calls via that reference. Access control SMOs are used to implement access restrictions (e.g., allow only a specific principal to call methods). Principal SMOs
1 With RBAC a principal can choose a specific role from a set of roles associated
with it. As it can execute only operations assigned to that role, security problems between different roles can be prevented. However, similar problems as with thread-based principals occur, if trusted and untrusted operations are assigned to the same role.
standard user
printer user/password database system administration
application
act as
system administrator act as
Fig. 1.Role-based principals
provide the principal information which is used for method invocations via a reference. Thus, a reference with a principal SMO is a capability for calls to a specific object on behalf of a specific principal.
As we do not want to implement capabilities (we want to implement access control lists), we additionally need virtual domains, which limit the capability property of such references and implement role-based principals.
The application’s classes do not need support for the SMOs. Initially few SMOs are attached to initial references. Afterwards, the SMOs themselves attach other SMOs to exchanged references. The SMOs are the only new mechanism we need: even the virtual domains are implemented just with SMOs.
The paper is structured as follows: In Section 2 we present SMOs that pro-vide principal information (principal SMOs) and implement access control lists (access control SMOs). Section 3 introduces virtual domains and explains how to implement object-group-based principals. In Section 4 we explain role-based principals and illustrate their advantages by an example.
2
Access control by meta objects
In this section, we describe our security model for access control using security meta objects. Our programming model is object-based and allows access to ob-jects only by invoking methods using object references, such as in Java with its bytecode verifier [11]. For simplicity, we do not allow access to instance variables through references, but our model could easily be extended to handle this.
As in most object-based models, we see object references as capabilities. A client can access an object only, if it possesses a valid object reference to that object. We extend this model by a concept that allows the attachment of special objects (meta objects, [7], [4]) to an object reference. These meta objects (Secu-rity Meta Objects, SMOs,[10]) are invoked for each security-relevant operation via the object reference. The meta objects are not visible to the application, so protected and unprotected object references look the same to the application.
SMOs are attached on a per-reference basis. There may be multiple references to an object, each with a different set of SMOs attached to it. Fig. 2 shows an object reference stored in variable v1, which is protected by the meta object anSMO. The meta object restricts the accessibility of the object anObject via this reference. There may be other references to the same object in the system, such asv2, which are not protected or protected by a different meta object.
We allow everyone to attach an SMO to an object reference. If several SMOs are bound to the same reference, they are invoked sequentially before access
anObject Variable Reference v2 anSMO Object v1
Fig. 2.A reference with an attached security meta object
is granted. A single SMO can be used to protect multiple references. It is not possible to detach an SMO from a reference unless the SMO removes itself.
SMOs are used for various tasks to control a method call (e.g., controlling access to an object or providing principal information). These tasks are either performed from the destination’s point of view or from source’s point of view, which is determined by the mode of the attachment. SMOs attached in desti-nation mode (destidesti-nation-attached SMOs) control usage of the reference from the destination’s point of view. SMOs attached insource mode (source-attached SMOs)control usage of the reference from the source’s point of view.
We introduce two types of SMOs: access control SMOs and principal SMOs (Fig. 3).Access control SMOsare used to restrict the accessibility of an object via a specific object reference. For this purpose they are attached to the reference in destination mode. Method invocations via the reference are incoming calls for them.Principal SMOsare used to provide principal information for method invocations via a specific object reference. They are source-attached. Method invocations via the reference are outgoing calls for them. As we will see later, SMOs are also used to keep track of exchanged object references.
principal SMO
aList access control SMO destination-attached SMO source-attached SMO
outgoing call incoming call
Fig. 3.Principal SMO and access control SMO
2.1 Access control SMOs
Access control SMOs are used to restrict the accessibility of an object. Before an object passes an object reference to an untrusted part, it can attach an access control SMO to that reference in destination mode. Then the access control SMO is invoked for each call via that reference. It gets information about the method to be invoked (e.g., parameters and principal information) and decides whether to allow or deny the invocation. Simple capabilities and access control lists can easily be implemented with these access control SMOs.
List l = new List(....); // a list reference SecurityMeta s = new AclSMO(...); // create ACL-SMO l = s.dstAttachTo (l); // attach SMO to obj ref x.untrusted_meth(l); // pass l to untrusted part class AclSMO extends SecurityMeta { // the MetaACL class
incomingCall (Object targetObj, // this method checks calls Method m, ParameterList p, // via protected refs on PrincipalList pList) // behalf of these pricipals
{ // meth. m is to be executed
if (pList.contains(someprincipal)) return;// only a specific principal else throw new SecException(); // may invoke methods }}
// untrusted part:
untrusted_meth(List lst) { lst.Get (...); } // call to list is checked
aList
lst
aclSMO
l s
trusted part untrusted part
Fig. 4.A simple ACL example
Example: We have a list and want to create a reference to the list that allows access only by a specific principal. Thus, we connect an SMO to the reference, which implements this policy. Fig. 4 shows an example in a Java-like syntax.
The first part of the program shows the creation and the attachment of the access control SMO. The method dstAttachTo attaches the SMO to the referencelin destination mode. Now the SMO restricts accesses via referencel and we can pass it to an untrusted application part. Assignments and parameter passing duplicate a reference including all attachments. In our example, the reference stored inlis propagated to an untrusted application part, where it is stored in variablelst. The untrusted application part is not able to circumvent the SMO’s access control policy. In our example we drop the only unprotected reference (which is in fact a pure capability) by overwriting the variable l.
The implementation of the classAclSMOis simple: Its methodincomingCall is invoked by the runtime system for each method call via the protected reference. It gets meta information about the call to be executed; for example, parameters of the call and list of principals. On behalf of these principals the call is to be executed.AclSMOallows only calls by the principalsomeprincipal.
The list does not need any support for security and the implementation of the SMO does not contain any special support for the list; it can be used for any class.
2.2 Principal SMOs
Principal SMOs provide the principal information, access control SMOs need for their decisions. Principal SMOs are attached to a reference in source mode. The caller of a method has to do this before using the reference to provide principal information and thus to identify itself at the destination. The method invocation is executed on behalf of that principal. In our example in Fig. 5 we attach a principal SMO to the list referencelst. Then every method invocation via referencelstis executed on behalf of the principalmyPrincipal.
List lst = ... ; // a protected list reference
SecurityMeta princSmo =
new PrincipalSMO(myPrincipal); // create the principal SMO lst = princSmo.srcAttachTo(lst); // attach SMO to object
lst.Get(...); // the call to lst is executed
// on behalf of myPrincipal class PrincipalSMO extends SecurityMeta { // the PrincipalSMO class
PrincipalSMO(Principal p) {...} // Constructor: store princ. void outgoingCall (..., PrincipalList pList) {
pList.add(p); // act as principal p
}} lst aList aclSMO principalSMO incomingCall outgoingCall
Fig. 5.Example with principal SMO and access control SMO
Fig. 5 shows the result: the access control SMO has been attached in destina-tion mode (withdstAttachTo); the principal SMO is attached in source mode (withsrcAttachTo). Calls via the reference invokeoutgoingCallof the princi-pal SMO (as it is source-attached) andincomingCallof the access control SMO (as it is destination-attached). The referencelstis a capability for calls to the list object on behalf of principalmyPrincipal.
3
Transitivity and virtual domains
In this section we show how our model supports transitive SMOs and virtual do-mains. Transitivity allows an automatic attachment of SMOs instead of attaching them manually. Virtual domains are needed to limit the capability property of references with principal SMOs.
3.1 Transitivity of access control
Object references are exchanged frequently in object-oriented applications. Of course it is not feasible to attach SMOs to every single object reference manually before passing it to other application parts. Transitive SMOs provide the means to perform this task automatically. Only the object references that are estab-lished initially between different application parts have to be protected manually. As all other references result from invocations via initial references, transitive protection protects them, too.
In the example in Fig. 6 (left part) our application part has protected a list reference with an access control SMO and entered it in a name server. Another application obtains this reference from the name server and calls theGetmethod of the list, which returns a reference to a list entry (right part). Before this refer-ence is actually returned, it is passed to the methodoutgoingRefof the SMO. This method protects the reference by attaching the SMO itself transitively be-fore it passes it on. So the list entry automatically becomes protected by the same access control list.
name server
app. part (later)
list app. part (initially)
name server list
Fig. 6.Transitivity example
To achieve full transitivity in all situations we also have to keep track of incoming references, such as parameters of method invocations at the list object. The SMO’s methodincomingRefis called for each such reference. As the SMO has to protect all references which are passed out via calls through that reference, incomingRefattaches the SMO in source mode.
The following code example shows an implementation of a transitive SMO: class TransitiveAclSMO extends SecurityMeta {
void incomingCall (...) {...}
Object outgoingRef(Object oRef) {return this.dstAttachTo(oRef);} Object incomingRef(Object iRef) {return this.srcAttachTo(iRef);} }
In Fig. 7 we give an example for transitivity with incoming and outgoing references. Initially (1) we have one reference (lst) to the listaList, which is protected by TransitiveAclSMO. Then we call lst.match, the search method of the list and pass a reference to a search-expression object as parameter (2). As this reference is an incoming reference,TransitiveAclSMOattaches itself in source mode (3). To figure out whether a list entryanEntrymatches the search
expression, the list object calls the match method of the search expression and passesanEntryas parameter (4). AsanEntryis an outgoing reference from the source-attached SMO’s point of view the method outgoingRefof the SMO is called. In this method the SMO protects the reference by attaching itself in destination mode (5). Thus, the reference entry automatically gets the same protection as the referencelst.
anEntry anEntry searchExpr aList entry lst anExpression anExpression transAclSMO ) (1) (3) src-attached (5) dst-attached dst-attached (2) lst.match( (4) searchExpr.match( )
Fig. 7.Completely transitive access control list
A similar transitivity implementation can be used for principal SMOs as well to achieve principal-information transitivity: All calls via exchanged references are executed on behalf of the same principal. Whether we need transitivity, depends on the application.
Transitive SMOs are explained in more detail in [10].
3.2 Virtual domains
There is one unsolved problem remaining: A reference with a principal SMO attached to it is a capability. If we pass such a reference, the receiver is able to invoke methods on behalf of the attached principal. Although we may want to have this semantics in special cases, we do not want it in general. In most cases the principal information should only be used by a specific application part. Virtual domains solve this problem.
Avirtual domainconsists of a set of objects. Inside such a domain references with a principal SMO can be passed. Thus inside a domain they are capabilities. References that are passed out of a domain loose their principal SMOs. Refer-ences that are passed in from other domains automatically get principal SMOs attached to them.
A virtual domain is not defined by the objects it contains, but by its bound-ary, which is built by special principal SMOs:border principal SMOs. If all border principal SMOs of a virtual domain use the same principal information, we get the object-group-principal semantics (domain-based principals). Note that we may have border principal SMOs with different principal information or even without principal information. As we need the border principal SMOs also to
build the boundary of a virtual domain, border principal SMOs without principal information also make sense.
Fig. 8 shows a virtual domain: All references into the domain and out of the domain have a border principal SMO attached to them.
00
11
00
11
00
11
00
00
11
11
00
11
000
111
domain virtual SMOs border principalFig. 8.A virtual domain
Let us now describe the functionality of a principal SMO which implements such semantics. Note that there must not be any reference into or out of our domain without border principal SMO attached to it. To implement such an SMO, we have to enforce the following:
– All initial references to and from a virtual domain have border principal SMOs attached to them. With most object-oriented systems this is easy to achieve. The only initial reference such a domain has, is the reference to a name server. We just have to attach a border principal SMO to that reference. If we have other global non-object-oriented access to objects (e.g., in Java the access to static variables), we can implement such accesses as if they were accesses to a name server.
– If new references are obtained from other domains (that is, they are passed via a border principal SMO as incoming references), they have to get a border principal SMO attached to them.
– If references with border principal SMO attached to them are passed out of our domain, we have to detach it. Such a reference is a reference to an external object.
– If references without border principal SMO attached to them are passed out of our domain, we attach a border principal SMO to them. These are references into our domain, so we have to attach an SMO to them to keep the border intact.
We can implement that semantics just with interacting SMOs. The runtime system does not need to know anything about virtual domains. We do not need to know, which object belongs to which virtual domain. This is especially ad-vantageous for the implementation of domains that merge (simply by dropping the SMO border), distributed domains, and dynamically changing domains.
4
Role-based principals
If we look at interacting application parts, we often have to face the problem that an application part should use different principal information for interaction in
different situations. Static object-group-based principals are not suitable in this case.
Example: We want to implement a printer spooler. The spooler has to interact with a printer and has to authenticate itself as printer spooler for this purpose (i.e., it uses printer-spooler principal information for method invocations). On the other hand it should not use the printer-spooler principal information when interacting with applications that want to use the spooler (i.e., applications that want to print). For example, if an application passes a text object to the spooler, the spooler should not use its printer-spooler principal information to access the text. Otherwise the application would be able to print text that is only accessible by the spooler (e.g., temporary spool files). This is similar to the Unix s-bit problem.
Our solution to this problem is role-based principals. Object references to other application parts are associated with different roles. These are implemented by different border principal SMOs that are attached to them. They may, for example, authenticate with different principal information.
There are at least two different solutions to that problem using SMOs: hi-erarchical object domains encapsulating the printing system and the disjunct interaction policy.
We present the disjunct interaction policy here. We assume disjunct inter-action, which means, that our application part interacts with other application parts, but our application part does not initiate interaction between these other application parts (although these other parts themselves may initiate such in-teraction).
Let us examine the printer-spooler example: The printer spooler interacts with the printers and with user applications that want to print. However the user applications do not have to interact with the printer directly. If a user application prints a text object, the printer spooler must not pass the reference to the printer, otherwise the printer and the user application would interact directly, which would violate the disjunct interaction policy. However, the printer spooler may interact with the text object to get its printable content, generate a new printable object with this content and pass that to the printer.
We need different principal SMOs, which are initially bound to the printer reference (spooler SMO) and to the printer-spooler reference that is used by applications (nobody SMO)2.
– The spooler SMO authenticates asprinter spooler, the nobody SMO does not implement authentication (or authenticates asnobody).
– References with a nobody SMO are not passed via a reference with spooler SMO and vice versa. This policy can be enforced by our SMOs.
– Both SMOs are completely transitive and implement the virtual-domain se-mantics.
2
Note that this reference is a reference from other applications to our printer spooler. The attached principal SMO must be destination-attached. Thus it is not used for calls to the printer spooler, but only for calls from the printer spooler to other applications (e.g., to the text object which is to be printed).
In Fig. 9 we illustrate the example. An application gets the reference to the spooler object (for example, via a name server), which has a nobody principal SMO attached to it. If the spooler accesses application files (e.g. the text to be printed), it authenticates asnobody. The spooler itself has references to a printer object and a printer-configuration object. It authenticates as spooler to them. These objects are protected by an access control list, which allows access only to the spooler.
acl text component
application printer spooler printer
spooler text
nobody princ. spool princ.
printer printer conf.
pass ref to spooler
Fig. 9.The printer spooler
Let us assume that an application has a reference to the printer-configuration object. As this object is protected by an access control list, the application is not able to access it. However, it may now try to pass the reference to the spooler object (e.g., to print its contents). With object-group-based principals this would succeed, as the printer spooler would be allowed to access the object. With our role-based principals it will not succeed. The reference gets a nobody SMO attached to it. Thus the printer spooler has now two references to the printer-configuration object with different principal information.
In special cases a sort of explicit authentication with more specific seman-tics is needed. We use transitive border principal SMOs which do not attach themselves, but attach a border principal SMO without principal information instead. For authentication we have to attach principal information explicitly to references. As long as we pass such a reference in our virtual domain, calls are authenticated. But if we pass the reference out of our domain and get it back, further calls are not authenticated. Although this looks similar to explicit authentication per call, there is a difference: If we store a reference in an object, we only have to attach a principal SMO initially. Then all calls via this reference are authenticated automatically.
5
Conclusion
In this paper we presented a very generic access control mechanism. It allows to implement all kinds of capabilities and access control lists. We focused on the question which principal information to use for authentication of method
invocations. We think, that the decision should not be based only on the source of a call or on the thread. The selection of a principal should be based on ob-ject references and it should depend from where the reference was (transitively) obtained from.
The SMOs we introduced were rather generic, so we can put these SMO classes into class libraries. Although the security mechanism is distributed (along the boundary of the virtual domain), the policy is kept in one place: it is im-plemented by the border principal SMO class. We are able to allow user-defined security policies, but we can also enforce mandatory policies: We can attach restrictive SMOs initially and disallow the user to detach SMOs himself.
We presented an example for the disjunct interaction policy, which cannot be implemented with thread-based or call-source-based principals. Without our SMOs either each call has to be authenticated explicitly, which leads to unstruc-tured code, or the reference-proxy problem (s-bit problem) arises.
We have implemented a Java prototype. We use front objects to implement SMO attachments, thus, we only have overhead for method invocations, if SMOs are attached. As most interaction takes place inside virtual domains, the overall overhead is acceptable.
References
1. Benantar, M.; Blakley, B.; Nadalin, A.: Approach to object security in Distributed SOM. IBM Systems Journal, Vol. 35 No. 2, 1996, New York
2. Dennis, J.B.; Van Horn, E.C.: Programming Semantics for Multiprogrammed Com-putations. Comm. of the ACM, March 1966
3. Ferraiolo, D.; Kuhn, R.: Role-based access control. In: 15th NIST-NCSC National Computer Security Conference, pp. 554-563, Baltimore, Oct. 1992
4. Klein¨oder, J.; Golm, M.: MetaJava: An Efficient Run-Time Meta Architecture for Java, Proc. of the Int. Workshop on Object Orientation in Operating Systems -IWOOOS’96, Seattle, IEEE, 1996
5. Lampson, B.: A Note on the Confinement Problem, In: Communications of the ACM 1973, October, 1973
6. Levy, H.: Capability-Based Computer Systems. Bedford, Mass.: Digital Press, 1984 7. Maes, P.: Computational Reflection, Ph.D. Thesis, Technical Report 87-2, Artificial
Intelligence Laboratory, Vrije Universiteit Brussel, 1987
8. Mitchell, J. ; Gibbons, J.; Hamilton, G. et.al.: An Overview of the Spring System. Proc. of the Compcon Spring 1994 (San Francisco), Los Alamitos: IEEE, 1994 9. OMG: CORBA Security, OMG Document Number 95-12-1, 1995
10. Riechmann, T.; Hauck, F. J.: Meta objects for access control: extending capability-based security. In: Proc. of the ACM New Security Paradigms Paradigms Workshop 1997, Great Langdale, UK, Sept. 1997 (to appear)
11. Sun Microsystems Comp. Corp.: HotJava: The Security Story, White Paper, 1995 12. Sun Microsystems Comp. Corp.: Java Security Architecture. JDK 1.2 Draft, 1997 13. Tanenbaum, A. S.; Mullender, S. J.; van Renesse, R.: Using sparse capabilities in a distributed operating system. Proc. of the 6th Int. Conf. on Distr. Comp. Sys., pp. 558-563, Amsterdam, 1986
14. Wallach, D. S.; Balfanz, D.; Dean, D.; Felten, E. W.: Extensible Security Archi-tecture for Java. Proc. of the SOSP 1997: pp. 116-128, Oct. 1997, Saint-Malo, France
15. Wulf, W.; Cohen, E.; Corwin, W.; Jones, A.; Levin, R.; Pierson, C.; Pollack, F.: HYDRA: The Kernel of a Multiprocessor Operating System. Comm. of the ACM, 1974
16. Wang, C.; Wulf, W.; Kienzle, D.: A New Model of Security for Distributed Systems. In: Proceedings of the 1996 ACM New Security Paradigms Workshop, 1996
