U.S. patent number 5,649,099 [Application Number 08/071,649] was granted by the patent office on 1997-07-15 for method for delegating access rights through executable access control program without delegating access rights not in a specification to any intermediary nor comprising server security.
This patent grant is currently assigned to Xerox Corporation. Invention is credited to David A. Nichols, Douglas B. Terry, Marvin M. Theimer.
United States Patent |
5,649,099 |
Theimer , et al. |
July 15, 1997 |
Method for delegating access rights through executable access
control program without delegating access rights not in a
specification to any intermediary nor comprising server
security
Abstract
A method in which access control programs (ACPs) permit
controlled delegation of access rights from clients to untrusted
intermediaries. ACPs are programs that encode arbitrary
specifications of delegated access rights. In the method, a client
creates an ACP and associates it with a request to a server, the
request being made through one or more intermediaries. When
processing a request received from an intermediary, the server
executes the access control program to determine whether or not to
grant the request.
Inventors: |
Theimer; Marvin M. (Mountain
View, CA), Nichols; David A. (Mountain View, CA), Terry;
Douglas B. (San Carlos, CA) |
Assignee: |
Xerox Corporation (Stamford,
CT)
|
Family
ID: |
22102692 |
Appl.
No.: |
08/071,649 |
Filed: |
June 4, 1993 |
Current U.S.
Class: |
726/4; 709/229;
711/163; 711/164; 719/330 |
Current CPC
Class: |
G06F
9/468 (20130101); G06F 21/6218 (20130101); H04L
29/06 (20130101); H04L 63/0807 (20130101); H04L
63/10 (20130101); H04L 63/20 (20130101); G06F
2221/2141 (20130101); G06F 2221/2149 (20130101) |
Current International
Class: |
G06F
21/00 (20060101); G06F 9/46 (20060101); H04L
29/06 (20060101); G06F 013/00 () |
Field of
Search: |
;395/725,650,600,700,187.01,186,200.03,490,491,684 ;380/23,4
;370/60 |
References Cited
[Referenced By]
U.S. Patent Documents
Other References
Eichin and Rochlis, "With Microscope and Tweezers: An Analysis of
the Internet Virus of Nov. 1988", 1989, pp. 326-343. .
J. E. Donnelley et al. "Resource Access Control in a Network
Operating System," Univ. of CA, Lawrence Livermore Lab. pp.
115-125. .
R. M. Needham et al. "Using Encryption for Authentication in Large
Networks of Computers," Communications of the ACM, Dec. 1978, vol.
21, No. 12 pp. 993-999. .
D. E. R. Denning "Cryptography and Data Security," (excerpts) '82,
pp. 7-16, 56-58, 101-126, 129-133, 161-179, 187-190, 191-329. .
Russel Sandberg et al. "Design and Implementation of the Sun
Network Filesystem," USENIX Association Summer Conference Proc.
Portland, 1985, Jun. 11-14,1985, pp. 119-130. .
A. S. Tanenbaum "Using Sparse Capabilities in a Distributed
Operating System," The 6th Intl. Conf. on Distributed Computing
Systems, Cambridge, Mass., May 19-23, 1986, pp. 558-563. .
Richard Stallman "GNU Emacs Manual," Fifth Edition, Emacs Ver. 18,
Oct. 1986. .
Xerox, "Authentication Protocol," Xerox System Integration
Standard, May 1986. .
James Gosling "SUNDEW: A Distributed and Extensible Window Sys.,"
USENIX, '86 Winter USNIX TECH. CONF., Colorado pp. 98-103. .
J. G. Steiner "Kerberos: An Authentication Service for Open Network
Syst." USENIX Winter Conf. Feb. 9-12, '88, TX, pp. 191-202. .
B.N. Bershad "Watchdogs: Extending the UNIX File System," USENIX
Winter Conference Feb. 9-12, 1988, Texas pp. 267-275. .
J.W. Stamos et al. "Remote Evaluation," ACM Trans. on Programming
Languages and Systems, vol. 12, No. 4, Oct. 1990 pp. 537-565. .
K. R. Sollins "Cascaded Authentication," Proceedings 1988 IEEE
Symposium on Security and Privacy Apr. 18-21, '88, CA pp. 156-163.
.
J. H. Howard et al. "Scale and Performance in a Distributed File
System," ACM Transactions on Computer Systems, vol. 6, No. 1, Feb.
1988, pp. 51-81. .
M. Satyanarayanan "Integrating Security in a Large Distributed
System," ACM Transactions on Computer Systems, vol. 7, No. 3, Aug.
1989, pp. 247-280. .
Morrie Gasser et al. "An Architecture for Practical Delegation in a
Distributed System," CH2884-5/90/0000/0020$01.00 .COPYRGT. 1990
IEEE pp. 20-30. .
J. K. Ousterhout "Tel: An Embeddable Command Language," USENIX
Association of the Winter 1990 USENIX Conference, Jan. 22-26, 1990,
Washington, D.C., USA pp. 133-146. .
SunOS.TM. Reference Manual, Sun Microsystems, (excerpts) Comm.
Commands, Misc. Ref. Man. Pages, Chapt. 1, 4, 8 and 14..
|
Primary Examiner: Barry, Esq.; Lance Leonard
Assistant Examiner: Luu; Le Hien
Attorney, Agent or Firm: Silverman; Alexander E.
Claims
What is claimed is:
1. In a computing system comprising a server, a client, and at
least one intermediary, a method of processing an ultimate request
to the server, the ultimate request being delivered to the server
as the final request in a chain comprising at least two linked
requests, the client and all the intermediaries each being
associated with one linked request of the chain, the intermediary
that delivers the ultimate request to the server being the final
intermediary in the chain and being designated as the requestor,
the method comprising the steps of:
using the requestor to present to the server the ultimate request
in conjunction with at least one executable access control program
comprising at least one sequence of computer program instructions,
the access control program being executable by a processor to
express a specification of a set of access rights;
using the server to execute each access control program thus
presented, each access control program being executed in a manner
such that said access control program is prevented from
compromising server security; and
if and only if the execution of each access control program thus
presented is successful, using the server to execute the ultimate
request in a manner consistent with the set of access rights, any
access rights not in the set of access rights not being delegated
to any intermediary nor being granted by the server.
2. In a system comprising a client, a server, and one or more
intermediaries that the client does not trust, a plurality of
communications channels that connect the client, the server, and
the intermediaries, one or more computing nodes, and a
communications network, a method for performing a request issued by
an intermediary to the server on behalf of the client, the method
comprising the steps of:
using the client to create a client request;
using the client to create an executable access control program,
the access control program comprising at least one sequence of
computer program instructions, the access control program being
executable by a processor to express a specification of an
arbitrary set of access rights to be delegated from the client to a
first intermediary untrusted by the client, any access rights not
in the set not being delegated to the first intermediary;
using the client to associate the access control program with the
client request;
in response to the client request, using the first intermediary and
zero or more additional intermediaries untrusted by the client to
issue intermediary requests, all these intermediary requests being
accompanied by the access control program;
receiving a final intermediary request in the server; and
using the server to execute the access control program in order to
determine whether or not to grant the final intermediary request,
the access control program being executed in a manner such that the
access control program is prevented from compromising server
security.
3. In a system comprising a client, a server, a number of
intermediaries, the number being greater than or equal to one, a
plurality of communications channels that connect the client, the
server, and the intermediaries, and computing hardware to execute
the client, server, and intermediaries and to support the
communication channels, a method for performing a client request
issued by the client to a first intermediary, the method comprising
the steps of:
using the client to create the client request;
using the client to create an executable access control program
comprising at least one sequence of computer program instructions
executable by a processor, the access control program being
executable to express a specification of a set of access rights to
be delegated from the client to the first intermediary, any access
rights not in the set not being delegated to the first
intermediary;
using the client to associate the access control program with the
client request;
using the client and a communications channel from the client to
the first intermediary to transmit the client request and its
associated access control program from the client to the first
intermediary;
using the first intermediary to generate a first intermediary
request;
using the first intermediary and a communications channel to issue
the first intermediary request and to transmit the access control
program along with the first intermediary request thus issued;
using the server to receive a service request and the access
control program;
using the server to make a determination whether the client
approves the service request by performing a test that comprises
the steps of:
using the server to execute the access control program, the access
control program being executed in a manner such that the access
control program is prevented from compromising server security;
and
using the server to check a value returned by the access control
program thus executed; and
if and only if the determination thus made by the server is that
the client approves the service request, using the server to
execute the service request, and otherwise using the server to deny
the service request.
4. The method of claim 1 wherein the number of intermediaries is
exactly one, wherein the first intermediary request and the service
request are one and the same, wherein the communications channel
used by the first intermediary to issue the first intermediary
request connects the first intermediary directly with the server,
such that when the first intermediary issues the first intermediate
request, the first intermediate request is transmitted directly to
the server.
5. The method of claim 3 wherein the access control program is a
procedure that takes as parameters a caller, an operation being
performed, and any arguments required for this operation, and that
returns an indication of whether or not the operation is
allowed.
6. The method of claim 3 additionally comprising the step of using
the client to digitally sign the access control program with a
digital signature associated with the client, and wherein the step
of using the server to make a determination whether the client
approves the service request further comprises an additional test
of using the server to verify that the access control program bears
a digital signature that is authentic and that is the client's.
7. The method of claim 3 wherein the step of creating an access
control program is performed independently of the server.
8. The method of claim 3 wherein the step of creating an access
control program is performed at run time contemporaneously with the
step of creating the client request.
9. The method of claim 1 wherein the number of intermediaries is
strictly greater than one, wherein the intermediaries are ordered
in an order from first to last, and:
a) wherein the step of using the first intermediary and a
communications channel to issue the first intermediary request and
to transmit the access control program along with the first
intermediary request thus issued further comprises the additional
steps of:
for each intermediary except the last:
using the intermediary to choose a next intermediary;
using the intermediary to create an additional intermediary
request;
using the intermediary to create an additional executable access
control program comprising at least one additional sequence of
computer program instructions executable by a processor, the
additional access control program being executable to express a
specification of a set of access rights to be delegated from the
intermediary to the next intermediary, any access rights not in
said set not being delegated to the next intermediary;
using the intermediary to associate the additional access control
program with the additional intermediary request; and
using the intermediary and a communications channel from the
intermediary to the next intermediary to transmit the access
control program, the intermediary request and its associated
additional access control program, and all additional access
control programs already created by other intermediaries, from the
intermediary to the next intermediary;
b) wherein the step of using the server to receive a service
request and the access control program further comprises the steps
of:
using the last intermediary to generate the service request;
and
using the last intermediary to issue the service request to the
server and to transmit the access control program and all
additional access control programs created by other intermediaries
to the server; and
c) wherein the step of using the server to make a determination
whether the client approves the service request further comprises
using the server to make additional determinations whether all
intermediaries except the last approve the service request by
performing additional tests, one additional test for each
intermediary except the last, each additional test comprising the
steps of:
using the server to execute the additional access control program
associated with the intermediary, said additional access control
program being executed in a manner such that said additional access
control program is prevented from compromising server security;
and
using the server to check a value returned by the additional access
control program thus executed.
10. The method of claim 9 additionally comprising the step,
executed for each intermediary except the last, of using the
intermediary to digitally sign the additional access control
program with a digital signature associated with the intermediary,
and wherein each additional test performed during the step of using
the server to make additional determinations whether all
intermediaries except the last approve the service request further
comprises the step of using the server to verify that the
additional access control programs bear digital signatures that are
authentic and that are the intermediaries'.
11. The method of claim 9 further comprising the step, performed
for each intermediary except the last, of using the intermediary to
designate an additional revocation object associated with a right
to be delegated that is among the rights of the set of access
rights of the specification of the additional access control
program.
12. The method of claim 3 wherein the access control program is a
computer program written in a programming language.
13. The method of claim 12 wherein the programming language is a
Turing-complete language and wherein the access control program
provides a functionality not providable by an access control
program written in a language that is not Turing-complete.
14. The method of claim 13 wherein the programming language is an
interpreted language and wherein the access control program is an
interpreted program.
15. The method of claim 12 in which the programming language is an
extension language and the server provides a core set of access
control concepts, and wherein the access control program extends
the core set of access control concepts provided by the server.
16. The method of claim 12 wherein the programming language
includes control constructs and the server has state information
that the server makes available to the access control program, and
wherein the access control program includes multiple possible paths
of execution and thereby provides a conditional access right that
is conditioned on the state information thus made available.
17. The method of claim 3 further comprising the step, performed by
a programmer, of using a template to specify portions of the access
control program to be created by the client.
18. The method of claim 3 wherein the server is chosen from the
group a file server, a database server, a print server, an
input/output server, or a compute server.
19. The method of claim 3 wherein the client is a user command
process associated with a user, the first intermediary is an
untrusted program, and the server is an operating system in the
context of which the user command process executes and the
untrusted program is to be executed.
20. The method of claim 3 wherein the at least one sequence of
computer program instructions is a sequence of computer program
instructions executable by a processor after conversion into a
machine-executable form, and further comprising the step of
converting the sequence of computer program instructions into the
machine-executable form.
21. The method of claim 20 wherein the converting step comprises
interpreting the sequence of computer program instructions with a
safe interpreter.
22. The method of claim 20 wherein the at least one sequence of
computer program instructions is a sequence of computer program
instructions written in an interpreted programming language, and
wherein the converting step comprises interpreting the sequence of
computer program instructions.
23. The method of claim 3 wherein the at least one sequence of
computer program instructions is a sequence of computer program
instructions directly executable by a processor.
24. The method of claim 3 wherein the step of using the server to
execute the access control program in a manner such that the access
control program is prevented from compromising server security
comprises accessing server resources with the access control
program only in a manner in which the client would be authorized to
access the server.
25. The method of claim 3 wherein the step of using the server to
execute the access control program in a manner such that the access
control program is prevented from compromising server security
comprises invoking with the access control program only server
system operation having no undesired side effects, regardless of
whether the server grants or denies access.
26. In a system comprising a client, a server, a number of
intermediaries, the number being greater than or equal to one, a
plurality of communications channels that connect the client, the
server, and the intermediaries, and computing hardware to execute
the client, server, and intermediaries and to support the
communication channels, a method for performing a client request
issued by the client to a first intermediary, the method comprising
the steps of:
using the client to create the client request;
using the client to create an executable access control program,
the access control program encoding a specification of a set of
access rights to be delegated from the client to the first
intermediary;
using the client to digitally sign the access control program with
a digital signature associated with the client;
using the client to associate the access control program with the
client request;
using the client and a communications channel from the client to
the first intermediary to transmit the client request and its
associated access control program from the client to the first
intermediary;
using the first intermediary to generate a first intermediary
request;
using the first intermediary and a communications channel to issue
the first intermediary request and to transmit the access control
program along with the first intermediary request thus issued;
using the server to receive a service request and the access
control program;
using the server to make a determination whether the client
approves the service request by performing a test that comprises
the steps of
using the server to execute the access control program, and
using the server to check a value returned by the access control
program thus executed,
performing an additional test comprising the step of
using the server to verify that the access control program bears
a
digital signature that is authentic and that is the client's,
and performing two further additional tests of
using the server to verify the identity of the first intermediary,
and
using the server to verify that the client has the rights that it
purports to delegate via the access control program; and
if and only if the determination thus made by the server is that
the client approves the service request, using the server to
execute the service request, and otherwise using the server to deny
the service request.
27. In a system comprising a client, a server, a number of
intermediaries, the number being greater than or equal to one, a
plurality of communications channels that connect the client, the
server, and the intermediaries, and computing hardware to execute
the client, server, and intermediaries and to support the
communication channels, and additionally comprising an
authentication server, an additional communications channel between
the authentication server and the client, and computing hardware to
execute the authentication server and the additional communications
channel, a method for performing a client request issued by the
client to a first intermediary, the method comprising the steps
of:
using the client to create the client request;
using the client to create an executable access control program,
the access control program encoding a specification of a set of
access rights to be delegated from the client to the first
intermediary;
using the client to associate the access control program with the
client request;
using the client to request an authentication ticket;
using the additional communications channel to transmit the request
for the authentication ticket to the authentication server;
using the authentication server to issue an authentication
ticket;
using the additional communications channel to transmit the
authentication ticket to the client;
using the client and a communications channel from the client to
the first intermediary to transmit the client request and its
associated access control program from the client to the first
intermediary;
using the first intermediary to generate a first intermediary
request;
using the first intermediary and a communications channel to issue
the first intermediary request and to transmit the access control
program along with the first intermediary request thus issued;
using the server to receive a service request and the access
control program;
using the server to make a determination whether the client
approves the service request by performing a test that comprises
the steps of
using the server to execute the access control program, and
using the server to check a value returned by the access control
program thus executed; and
if and only if the determination thus made by the server is that
the client approves the service request, using the server to
execute the service request, and otherwise using the server to deny
the service request.
28. The method of claim 27 wherein the additional communications
channel is a secure channel.
29. The method of claim 27 wherein the step of using the server to
make a determination whether the client approves the first
intermediary request further comprises an additional test of using
the server in conjunction with the authentication server and a
channel between the server and the authentication server to verify
that the access control program is authentic and is the
client's.
30. The method of claim 29 wherein the channel between the server
and the authentication server is a secure channel.
31. In a system comprising a client, a server, a number of
intermediaries, the number being greater than or equal to one, a
plurality of communications channels that connect the client, the
server, and the intermediaries, and computing hardware to execute
the client, server, and intermediaries and to support the
communication channels, a method for performing a client request
issued by the client to a first intermediary, the method comprising
the steps of:
using the client to create the client request;
using the client to create an executable access control program,
the access control program encoding a specification of a set of
access rights to be delegated from the client to the first
intermediary;
using the client to associate the access control program with the
client request;
using the client and a communications channel from the client to
the first intermediary to transmit the client request and its
associated access control program from the client to the first
intermediary;
using the first intermediary to generate a first intermediary
request;
using the first intermediary and a communications channel to issue
the first intermediary request and to transmit the access control
program along with the first intermediary request thus issued;
using the server to receive a service request and the access
control program;
using the server to make a determination whether the client
approves the service request by performing a test that comprises
the steps of
using the server to execute the access control program, and
using the server to check a value returned by the access control
program thus executed;
if and only if the determination thus made by the server is that
the client approves the service request, using the server to
execute the service request, and otherwise using the server to deny
the service request;
using the client to designate a revocation object at the server
associated with a right to be delegated that is encoded in the
specification of the access control program;
if and only if the server executes the service request, using the
server to test for the existence of the revocation object thus
designated; and
if and only if the server finds that the revocation object exists,
using the server to grant the delegated right associated with the
revocation object, and otherwise using the server to deny the
delegated right associated with the revocation object.
32. The method of claim 31 further comprising the step of using the
client to revoke the right associated with the revocation object by
eliminating the revocation object prior to the server's execution
of the service request.
33. The method of claim 31 wherein the server is a file server and
the revocation object is a file stored by the server.
34. The method of claim 31 wherein the client designates the
revocation object independently of the server.
35. The method of claim 31 wherein the client designates the
revocation object at run time contemporaneously with the step of
creating the client request.
36. In a distributed file system comprising a plurality of nodes,
each node comprising a processor and memory, a plurality of
processes including at least one client, at least one file server,
and at least one intermediary, each process executing on its own
unique node, and a plurality of communications channels that
connect the processes to one another, a method for performing a
client request issued by the client to the intermediary, the method
comprising the steps of:
using the client to create the client request;
using the client to create an executable access control program,
the access control program encoding a specification of a set of
access rights to be delegated from the client to the
intermediary;
using the client to digitally sign the access control program;
using the client to associate the access control program thus
digitally signed with the client request;
using the client and a communications channel from the client to
the intermediary to transmit the client request and its associated
access control program from the client to the intermediary;
using the intermediary to generate an intermediary request;
using the intermediary and a communications channel to issue the
intermediary request and to transmit the access control program
along with the intermediary request thus issued;
using the server to receive a service request and the access
control program;
using the server to make a determination whether the access control
program is valid by performing a test that comprises the steps
of:
using the server to verify that the access control program bears a
digital signature that is authentic and that is the client's;
using the server to verify the identity of the first intermediary;
and
using the server to verify that the client has the rights that it
purports to delegate via the access control program;
if and only if the server thus determines that the access control
program is valid, using the server to make a determination whether
the client approves the service request by performing a test that
comprises the steps of:
using the server to execute the access control program; and
using the server to check a value returned by the access control
program thus executed; and
if and only if the determination thus made by the server is that
the client approves the service request, using the server to
execute the service request, and otherwise using the server to deny
the service request.
Description
COPYRIGHT NOTIFICATION
A portion of the disclosure of this patent document contains
material which is subject to copyright protection. The copyright
owners have no objection to the facsimile reproduction, by anyone,
of the patent document or the patent disclosure, as it appears in
the patent and trademark office patent file or records, but
otherwise reserve all copyright rights whatsoever.
Software Appendix
An appendix comprising two printed files is included as part of
this application. The first file is entitled "Diffs," and is 28
pages long plus a cover sheet. It represents the differences in
source code between release 3 of the Andrew File System (as it
appeared on the Aug. 19, 1990 Mt. Xinu release tape of the Mach
operating system) and a modified version of release 3 of the Andrew
File System, described below, that embodies the method of the
present invention. The second file is entitled "TCLDiffs" and is 25
pages long plus a cover sheet. It represents the differences in
source code between release 3.3 of Tool Command Language and a
version of Tool Command Language modified from release 3.3 to
support the embodiment of the invention in the modified version of
the Andrew File System as described below. The modifications made
to Andrew File System release 3 and Tool Command Language release
3.3 in order to produce the embodiment of the present invention in
the modified version of the Andrew File System as described below
represent unpublished work, Copyright .COPYRGT. 1991 Xerox
Corporation. All rights reserved. Copyright protection claimed
includes all forms and matters of copyrightable material and
information now allowed by statutory or judicial law or hereafter
granted, including without limitation, material generated from the
software programs which are displayed on the screen such as icons,
screen display looks, etc.
BACKGROUND OF THE INVENTION
The present invention relates to computing systems and more
particularly to client-server systems, including but not limited to
distributed client-server systems.
In a distributed client-server system, a client program often
requires an intermediary to perform an operation on some server.
The intermediary must be able to convince the server that it is
operating on behalf of the client and hence that it should be
granted the right to perform the requested operation. Furthermore,
to limit exposure to untrusted intermediaries, the client will want
to grant to the intermediary only that subset of its rights that
are necessary for completing the requested operation.
An example of such a situation is the use of a print server to
print a file that resides on a file server. The initiating user
would like to grant the print server access to the file to be
printed so that it can directly retrieve the file from the file
server. However, the user would like to prevent the print server
from being able to retrieve any other files. The user might also
wish to place a time limit on how long the print server has access
rights to the file.
A second example is remote compilation on a compute server. The
compute server must be given read access to all the relevant source
files. It should also be permitted to create or overwrite the
relevant object files while being prevented from modifying source
files. Additionally, suppose the compute server does a
recompilation as a set of parallel tasks, each running on a
separate machine. Then the server will want to delegate some of the
rights it has acquired to other hosts that are performing
subtasks.
This example can be further complicated if the files and
directories involved are owned by someone other than the user who
is invoking the compilation. The user (e.g., as member of a group)
may have permission to read and write various files in a directory,
but may lack permission to modify the access controls of those
files or the directory they are in. Hence it may not even be
possible for the user to delegate access rights to a third
party.
A more application-specific example is a self-paced course in which
students submit their homework assignments by creating a file in a
well-known directory. The solutions to each homework assignment
also reside in files in that directory; however, each student
should only be given access to the solutions after they have handed
in their answers for that assignment. The access control
specification in this case is that only students in the class may
read or write files in the directory, no student in the class may
read a solution file without having already written a corresponding
homework file and no student may write any given homework file more
than once.
Finally, one may wish to limit access to resources that can be
subdivided, such as electronic funds. This implies being able to
specify quantitative limits on resources for which access rights
have been delegated.
Techniques proposed in the prior art for granting/delegating access
control have centered around access control lists and capability
schemes. Access control lists (ACLs) are lists of (name, access
right) tuples. Such lists may be implemented as bit tables, linked
lists, or other suitable data structures. Servers maintain ACLs and
use them to decide whether or not to grant any given access
request. Capability schemes are based on capability tokens that
servers hand out to clients. A requestor, such as an intermediary
between a client and a server, presents a capability token along
with an access request to prove that the requestor has the right to
make the request of the server.
Both ACL- and capability-based systems provide ways for a client to
delegate its access rights to an intermediary, but provide only
limited facilities for restricting the rights granted to the
intermediary. ACL-based systems can deal with restricted delegation
by allowing the creation of roles, which explicitly represent the
entity to whom a restricted set of access rights is being
delegated. Capability-based systems enable restricted delegation by
either handing out multiple tokens or by handing out tokens that
can be securely subsetted to a certain degree. Both of these
approaches to restricted delegation depend on servers' having an
explicit understanding of all access controls: Concepts such as
restrictions over file types, access time limits, the homework
example restrictions, or resource quotas must be implemented at the
servers. Servers must know in advance of any client requests all
the various access rights and restrictions that clients may want to
delegate.
With either ACL- or capability-based systems, if a client wishes to
enforce access controls that are not understood by the server(s)
available to him, he has only one option, namely, to use or build
other servers. For example, consider a distributed file system that
does not ordinarily support access time limits. An example is the
Unix distributed file system known as NFS, which is described, for
example, in Russell Sandberg, David Goldberg, Steve Kleiman, Dan
Walsh, and Bob Lyon, "Design and Implementation of the Sun Network
File System," in Proceedings of the Summer 1985 USENIX Conference
(Portland, Ore., June 1985) at 119-130. To build a print service
that understands access time limits on NFS files requires that a
new print server be built that both understands time-limit-based
access controls and is trusted with access to all NFS files that
any clients might wish to print. Similarly, to implement the
homework example on top of prior art file servers (or any file
servers whose access controls lack the concepts necessary to
express the homework constraints) requires that someone build a
"homework server." Furthermore, students' ability to hand their
homework in and receive solution sets back depends on the
availability of this homework server.
To better understand the limitations of the prior art, it is
helpful to consider an analogy. Suppose that a movie theater shows
ten different movies. Some are suitable for viewers of all ages,
while others are suitable only for adults. Like most movie
theaters, this theater sells tickets separately for each individual
movie. A patron who holds a ticket for, say, "Gone With the Wind,"
is thereby entitled to see "Gone With the Wind" but is not entitled
to see "Jaws" or "Unforgiven" or any other movie playing at the
theater.
Now suppose that a parent wishes to send her child, who is thirteen
years old and not to be trusted, to see a movie unaccompanied. The
parent wants the child to see only "Grated" movies, that is, movies
deemed suitable for viewers of all ages, and no other movies. She
is concerned that if she simply gives the child money to purchase a
ticket, left to his own devices the child (possibly with the
assistance of an adult or older teenager posing as his "guardian")
will purchase a ticket to an "R-rated" movie intended for more
mature viewers. Thus the parent runs the risk that if she tells her
child to go see "Bambi," the child will sneak in to see "Basic
Instinct." What the parent really wants is to be able to purchase
in advance, and give to her child, a movie ticket redeemable for
access to any G-rated movie and for no other movies. Unfortunately
the movie theater does not sell such tickets. Short of persuading
the movie theater to change its ticket-selling policies, the parent
is stuck with either having to accompany her child to the theater
or else running the risk that the child will disobey her.
It can be seen that the parent is analogous to a client program,
the child to an intermediary, the movie theater to a server, and
the movie ticket to a capabilities token in a capability-based
system. The parent-client is stuck with the kind of tickets that
the theater-server sells, and cannot order a custom-made ticket
that would allow her to grant some independence to her
intermediary-child while simultaneously maintaining a certain
measure of control over the intermediary-child's behavior. The
system provides no straightforward way for a client to design a
restricted set of access privileges, e.g., at run time, and
delegate these to a potentially untrustworthy intermediary.
What is needed as an alternative to embedding an ever-increasing
multitude of access control concepts into each server or building
an ever-increasing set of application-specific "front-end" servers
is to provide clients and servers with a language with which they
can dynamically build generalized capabilities and define
application-specific access rights at the time those rights are to
be delegated.
SUMMARY OF THE INVENTION
The present invention provides a method for delegation in
client-server systems that is based on client-manufactured access
control programs (ACPs) that can encode arbitrarily general access
rights specifications. According to one aspect of the invention, an
intermediary making a request of a server on behalf of a client
presents an appropriate client-created ACP along with the request.
The server executes the ACP to determine whether or not the
requestor--that is, the intermediary--has been granted by the
client the right to make the given request. If and only if the
requestor has been granted the right to make the given request does
the server carry out the request. In another aspect of the
invention, two or more intermediaries stand between the client and
server. Each intermediary creates its own additional ACP in order
to delegate some or all the rights it has to the next intermediary
in the chain. The server checks all the ACPs before carrying out a
request issued by the last intermediary in the chain.
An important advantage of the method of the present invention is
that a wide range of applications and access control schemes can be
built on top of any server that implements an ACP interpreter and a
relatively small number of access control concepts. Another
advantage is that the method finds applicability in distributed and
nondistributed systems. Still another advantage is that ACPs can be
digitally signed to prevent their forgery, thus allowing them to be
freely passed around or even published. A further understanding of
the nature and advantages of the present invention may be realized
by reference to the remaining portions of the specification and the
drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1A schematically depicts a client-server system suitable to
the method of the present invention;
FIG. 1B schematically depicts a client request and an intermediary
request that is also a service request;
FIG. 1C schematically depicts a client request, a first
intermediary request, and additional intermediary requests, the
last of which is also a service request;
FIG. 1D schematically depicts an example of multiple
contemporaneous requests;
FIG. 2A schematically depicts an authenticated remote procedure
call with no delegation of rights, as in the prior art;
FIG. 2B schematically depicts a remote procedure call with
delegation of rights via an access control program;
FIG. 2C is a flowchart illustrating the steps of a remote procedure
call with delegation via an access control program;
FIG. 2D is a flowchart illustrating the steps for revoking access
privileges using revocation objects with an example ACP;
FIG. 2E schematically depicts an example that illustrates the use
of revocation objects in a situation wherein a single client
request generates two intermediary requests;
FIG. 2F is a flowchart illustrating the sequence of steps followed
in the example of FIG. 2E;
FIG. 3A schematically depicts a remote procedure call with chained
delegation;
FIG. 3B is a flowchart illustrating the steps of a remote procedure
call with chained delegation;
FIG. 4A is a flowchart illustrating the steps of the authentication
protocol in the Andrew File System of the prior art;
FIG. 4B is a flowchart illustrating the steps of the authentication
protocol in a version of the Andrew File System modified according
to a specific embodiment of the present invention; and
FIG. 4C schematically depicts an access control program passed in
an authentication ticket via a remote invocation facility.
DESCRIPTION OF SPECIFIC EMBODIMENTS
The disclosures in this application of all articles and references,
including patent documents, are incorporated herein by reference.
Also incorporated by reference are sections 1C, 2V, and 3V of the
SUN Solaris 1.1 User Manual, respectively for their descriptions of
the Unix command rsh, the Unix command stat, and the Unix setuid
facility.
1. Introduction
1.1 Overview and Design Considerations
To get an overview of ACPs, it is helpful to begin with some
illustrative analogies. Returning for a moment to the movie theater
analogy given earlier, recall that the parent wants to be able to
give her child access to any G-rated movie but to no other movies.
The parent would like to be able to purchase an advance ticket
redeemable for G-rated movies. Better still, the parent would like
to avoid the trouble of advance purchase. She would like to be able
to write a check for the price of admission to the theater, say $7,
with special instructions on the check as follows: "Sell my Child a
ticket to a G-rated movie only; pay to Theater $7 for this purpose.
Signed, Parent." The theater would accept this check in lieu of
cash and give the child access to any G-rated film. Of course, the
theater would first ask the child for identification, to be sure
that the child was indeed the Child mentioned on the check. Also
the theater would check Parent's signature to ensure that the check
was not forged.
Translating this example to the client-server domain, the signed
check with special instructions is analogous to an ACP of the
present invention. The parent-client writes a "check"--an ACP--that
grants the child-intermediary only those access rights that the
parent-client specifically delegates. The child-intermediary
presents the check to the theater-server, who confirms the
child-intermediary's identity, verifies the parent-client's digital
signature on the ACP, and then executes the ACP to determine
whether to grant the child-intermediary access to a particular
movie-resource.
In another analogy, consider a person who signs a power-of-attorney
document. The power-of-attorney document delegates to an attorney
certain rights to do on the person's behalf what the person could
do for himself, for example, to draw funds from the person's bank
account. Importantly, the person can delegate to the attorney only
such rights as he actually has; he cannot, for example, give the
attorney the right to draw funds from somebody else's bank account.
The person signs the power-of-attorney document to prove that the
document is genuine. When the attorney presents the document to a
third party, such as a bank, the attorney also presents her own
identification to show that the attorney is who she purports to be.
It can be seen that the person is analogous to a client, the
attorney to an intermediary, the bank to a server, the client's
bank account to a resource controlled by the server, and the
power-of-attorney document to an ACP. Before allowing the
attorney-intermediary to draw funds, the bank-server confirms the
attorney-intermediary's identity and authenticates the ACP by
verifying the person-client's digital signature attached to the
ACP. Thereafter the bank-server reads the power-of-attorney
document-that is, executes the ACP. If all is in order, the
bank-server then allows the attorney-intermediary to draw funds
from the person-client's account-resource on the person-client's
behalf.
Several considerations arise in the design of an architecture
incorporating access control programs. These include: how ACPs are
transmitted between the interested parties-that is, between the
client, server, and intermediaries; how ACPs are used by the
servers that receive them; how powerful the language that is used
to write ACPs should be; how ACPs are revoked once issued; and how
ACPs can be used to restrict the rights delegated by other ACPs.
The following sections of the description address these
considerations and also describe a specific embodiment of the
invention that integrates ACPs into a particular file system called
the Andrew File System.
1.2 Glossary
The following terms are intended to have the following general
meanings:
AFS: "Andrew File System": a particular distributed file
system.
Access Right: The right to obtain access to or use some resource.
Examples: the right to obtain read access for a particular file;
the right to execute a particular program. Synonyms: "right";
"privilege."
Access Control List: A list of access rights for a particular
resource.
Access Control Program: A programmatic specification of access
rights.
Authentication: The act of checking that something or someone is
what they claim they are.
Authentication Server: A trusted program or machine that can
authenticate various things and/or that can issue encrypted data
items that others can use for authentication purposes.
Authentication Ticket: The encrypted data items that an
authentication server provides to its clients for authentication
purposes.
Capability: A token of some sort that can be used as proof of some
access right.
Check (name, resource, request): A function used by a server in
some embodiments of the present invention. This function checks
whether the user or process whose name is "name" has access rights
to "resource" that allow "request" to be performed on
"resource".
Client: A program that desires access to some resource or operation
controlled by a server.
Client Request: A request for access to some resource or operation
that is controlled by a server.
Client-Server System: Any system in which resources are
managed/controlled by server programs/processes and requests for
access to and use of those resources are made by client
programs/processes.
Communications Channel: A means by which two parties can reliably
communicate with each other.
Create (resourceName, revocationName): A function that a client can
request of a server that will create a revocation object with name
"revocationName" for the server's resource named by
"resourceName".
Destroy (revocationName): A function that a client can request of a
server that will destroy an existing revocation object whose name
is "revocationName". Only the client who created a revocation
object may destroy it.
Digital Signature: A property private to a user or process that is
used for signing sequences of data items. A digital signature for a
sequence of data items is a unique data value that is a function of
the private property and the sequence of data items to be
signed.
Initiator: The original client of a request; the one who has access
rights allowing the request without need for delegation of access
rights from some other party.
Intermediary: Someone making a request on behalf of some other
client. An intermediary must receive delegated access rights in
order to successfully make a request to a server.
Intermediary Request: The request made by an intermediary on behalf
of some other client.
Kerberos protocol: A particular authentication protocol.
Key: As in encryption key.
NFS: "Network File System"--a particular distributed file
system.
Privilege: See "access right."
Revocation Object: An object controlled by a server that can be
destroyed at the request of a client in order to invalidate all or
part of an access control program that that client has created.
Right: See "access right."
Role: An artificial user identity that has been created in order to
specify a specific set of access rights; for example, those
pertaining to some particular job or administrative function.
rsh: A Unix command that executes a program on another machine from
the one that "rsh" is invoked on.
Secure Channel: A communications channel whose contents cannot be
monitored by third parties.
Server: A program that controls resources that various clients of a
system may wish to use or gain access to.
Service Request: A request to a server for access to or use of some
resource.
stat: A Unix system call that returns information about a
particular file, including its last modification time and who may
access it in what fashion.
Template: A prototype for an access control program, containing
various fields that must be filled in with specific values in order
to instantiate a specific access control program.
Thread of Computation: A specific sequence of computer instructions
actually executed by a computer. A computer can interleave the
execution of multiple threads of computation by running multiple
programs "simultaneously".
2. The Method
2.1 System configuration
FIG. 1A illustrates a system configuration suitable to the method
of the present invention. System 1 comprises client 5, server 10,
and one or more intermediaries 15, all connected to one another via
communications network 20 that comprises a plurality of channels
25. System 1 can in some embodiments further comprise additional
servers, clients, and intermediaries (not shown). Server 10 manages
a resource 11 to which client 5 has access rights. Client 5 wants
to delegate some or all of these rights to one or more of the
intermediaries 15.
Client 5, server 10, and intermediaries 15 are processes that
execute on one or more computing nodes (not shown). Each process is
a software entity that comprises an address space (or protection
domain), one or more threads of execution, and possibly one or more
input/output streams. Each node is a computer comprising memory and
one or more processors. Typically, but not always, processes are
associated one-to-one with nodes, so that each process executes on
its own node. Threads need not be associated one-to-one with
processors.
It is assumed that each process is protected from every other
process. Thus where all the processes-client, server, and
intermediaries-execute on a single node, each process has its own
protected address space in the node's memory. Where different
processes execute on different nodes, each node is assumed to have
its own individual memory that cannot freely be accessed by other
nodes.
The processes communicate with one another through communications
network 20. Communications network 20 comprises channels 25 through
which the various processes can communicate with one another. Where
all the processes execute on a single node, the communications
network is a set of interprocess communication links that also
execute on the node. Where different processes execute on different
nodes, the communications network comprises hardware links and
software protocols through which the nodes can communicate with one
another. The communications network can, for example, be a local
area network or a wide area network and can, for example,
incorporate wire, coaxial cable, fiber optic, or wireless hardware
links. The communications network can provide for data encryption
in some embodiments.
Server 10 can be any process that controls a resource shared by
multiple processes. Without limitation server 10 can be, for
example, a storage server, such as a file server or database
server; an input/output server, such as a print server; a compute
server or remote execution server, such as a supercomputer or
mainframe that is shared by multiple users; or a process control
server, such as a robot or computer-controlled manufacturing
machine. Where the server is a storage server, the server can
provide for data encryption in some embodiments.
Resource 11 can be anything upon which server 10 can perform
operations on behalf of other processes. Thus, for example, if
server 10 is a file server, resource 11 can be a file or a set or
system of files; if server 10 is a print server, resource 11 can be
a printer or a print queue; if server 10 is a compute server,
resource 11 can be a compiler, graphics package, numerical
simulation code, or any other program that the server can execute;
if server 10 is a remote on-line banking computer, resource 11 can
be a bank account; and so forth without limitation. Put another
way, resource 11 is something that a client or intermediary can
use, access, or do through server 10. It will further be
appreciated that resource 11 can be one of a plurality of resources
(not shown) controlled by server 10.
The bulk of the description given herein speaks as though system 1
comprises a single client, a single server, and one or more
intermediaries, as depicted in FIG. 1A. Accordingly, the term
"client" is most often used herein to indicate the process that
issues an initial request, "server" to indicate the ultimate
process that responds to the request, and "intermediary" to
indicate a process situated between the client and the server.
However, as noted above, system 1 can in some embodiments comprise
multiple servers and clients, each communicating with the remainder
of system 1 through communications network 20. Moreover, it will be
appreciated that the terms "server," "client," and "intermediary"
are in some sense relative terms, in that the same process can be
viewed as a client with respect to one process, a server with
respect to another, and an intermediary with respect to a third.
For example, in a case in which a client issues a request to a
server through a chain of several intermediaries, each intermediary
other than the last one in the chain effectively stands in a client
relationship to the server, and each intermediary other than the
first one in the chain effectively stands in a server relationship
to the client. As another example, consider once again the case in
which a client, for instance a workstation, uses a print server to
print a file that resides on a file server. In this example, the
print server is an intermediary with respect to the client
workstation, and the file server is the server. Now suppose that a
later time the same client workstation wants to use the print
server to print a different file that is stored locally by the
print server, using certain header information to be supplied by a
second workstation. Now the second workstation becomes the
intermediary, and the print server is the ultimate server with
respect to the client workstation.
In some embodiments, as is described more fully below, the
invention contemplates the authentication of ACPs by means of
digital signatures that can be verified by server 10. In other
embodiments, to support ACP authentication system 1 further
comprises an authentication server 30 that communicates with the
rest of system 1 through communications network 20 via one or more
secure channels 35. This is shown in FIG. 1A. Still other kinds of
ACP authentication can be used within the scope of the
invention.
In some embodiments, as is described more fully below, the
invention contemplates two-party authentication, such that server
10 can identify or authenticate the client 5 and each intermediary
15. Authentication server 30 and its associated secure channels 35
can be included in system 1 for the purpose of two-party
authentication, whether or not authentication server 30 is also
used to support ACP authentication. Various other kinds of
two-party authentication can also be used within the scope of the
invention.
In some embodiments, as is described more fully below, the
invention contemplates revocation objects associated with ACPs. In
such embodiments, to support revocation objects server 10 has
associated with it stable storage 12 that is accessible to server
10. "Stable" data storage is data storage wherein the stored data
will survive a server failure, for example an unexpected loss of
power to the server. Such storage is typically in the form of a
disk file or nonvolatile medium. In embodiments where server 10 is
a file server and the server's associated resource 11 is file
storage, stable storage 12 can be part of, or the same as, resource
11. This is the situation shown in FIG. 1A. In other embodiments
stable storage 12 can be separate and distinct from resource
11.
2.2 Requests
The present invention contemplates the use of ACPs in requests that
involve a client, a server, and one or more intermediaries
interposed between the client and server. It will be observed that
the term "request" can be used in different ways. For example, in
the case of a client that makes a request to a server via a single
intermediary (or, put differently, the case of a single
intermediary that makes a request on behalf of a client), the term
"request" is used variously to refer to the client's request to the
intermediary, the intermediary's request to the server, and to the
overall request from the client to the server. In the case of a
client that makes a request to a server via a chain of
intermediaries (or, put differently, the case of a
last-in-the-chain intermediary that makes an ultimate request of a
server on behalf of the client and all preceding intermediaries in
the chain), the term "request" is used to refer variously to the
client's request to the first intermediary in the chain, the first
intermediary's request to the second intermediary in the chain, and
so on down the chain through the last intermediary's request to the
server, as well as to the overall request from the client to the
server.
In the case of the single intermediary, the term "client request"
can be used more precisely to indicate the client's request to the
intermediary, the term "intermediary request" to indicate the
intermediary's request to the server, and the term "service
request" to indicate the request received by the server, which in
this case is the same as the intermediary request. This is
illustrated in FIG. 1B. Client 50 issues request 51, which is a
client request, to intermediary 55. In complying with client
request 51, intermediary 55 issues its own request 56 to server 60.
Request 56 is an intermediary request because it is issued by an
intermediary. It is also a service request because it is received
by a server.
In the case of multiple intermediaries, the term "client request"
can be used more precisely to indicate the client's request to the
first intermediary, the term "intermediary request" to indicate any
intermediary's request to another intermediary or to the server,
the term "first intermediary request" to indicate the first
intermediary's request to the second intermediary, the term
"additional intermediary request" to indicate the second or a
higher-numbered intermediary's request to the next intermediary in
the chain, and the term "service request" to indicate the last
intermediary's request to the server. This is illustrated in FIG.
1C for the case of three intermediaries. Client 70 issues request
71, which is a client request, to first intermediary 75. In
complying with client request 71, first intermediary 55 issues its
own request 76 to second intermediary 80. Request 76 is an
intermediary request because it is issued by an intermediary, and
more particularly is a first intermediary request because it is
issued by the first intermediary. Second intermediary 80, in turn,
issues its own request 81 to third intermediary 85. Request 81 is
an intermediary request, and more particularly is an additional
intermediary request because it is issued by an intermediary other
than the first. Finally, the third and last intermediary 85 issues
request 86 to server 90. Request 86 is the ultimate and final
request in the chain. It is an intermediary request, and more
particularly is an additional intermediary request. It is also a
service request because it is received by the server.
It should be noted that at any time there can be an arbitrary
number of requests issued by the client or by any intermediary. An
example is shown in FIG. 1D. Client 100, a user workstation, issues
three client requests 101, 102, and 103. Request 101 is a request
to intermediary 105, a print server, to print a file 111 that is
stored on file server 110. In response to request 101 intermediary
105 issues service request 106 to server 110. Request 102 is a
request to intermediary 115, a compute server, to compile a source
code file 112a on file server 110 with the resulting object code to
be saved in file 112b on file server 110. In response to request
102 intermediary 115 issues a service request 116a to server 110,
asking to read the source code file 112a. Later, after compilation
is complete, intermediary 115 issues another service request 116b
to server 110, asking to write the object code file 112b. Request
103 is a request to intermediary 120, a network server, to access a
database 131 located on server 130, a database server at a location
remote from client 100. In response to request 103, intermediary
120 issues a first intermediary request 121 to intermediary 125, a
network server at the remote location. Intermediary 125 then issues
an additional intermediary request 126, which is the service
request, to server 130 on behalf of client 100 and intermediary
125.
In what follows, requests are sometimes referred to as remote
procedure calls (RPCs). This is because requests take the form of
RPCs in certain embodiments of the invention, notably in the
embodiment of the invention in a modified version of the Andrew
File System as described below. It is to be understood that
referring to requests as remote procedure calls or RPCs is merely a
convenient shorthand that implies no loss of generality. Other
kinds of request besides RPCs are very much within the scope of the
invention.
2.3 Delegation via ACPs
The present invention contemplates the use of ACPs in requests such
as remote procedure calls that involve a client, a server, and one
or more intermediaries interposed between the client and server.
For ease of exposition, however, the case of an authenticated
remote procedure call that does not involve any intermediaries or
delegation of rights will briefly be considered first. This case,
which is known in the prior art, is shown in FIG. 2A. Client
I.sub.0 makes an RPC to a server S, the call being of the form "op
(object . . . )". When the server S receives the call, it must
determine whether or not to execute the request. The server S
proceeds in two steps:
1. First, S verifies the identity of the caller I.sub.0. This it
does using authentication protocols such as, for example, those
described by R. M. Needham and M. D. Schroeder in their article
"Using Encryption for Authentication in Large Networks of
Computers," Communications of the ACM 21(12) 993-999, Dec.
1978.
2. Second, S verifies that I.sub.0 has permission to perform this
request. For example, S calls a function Check (I.sub.0, op,
object, . . . ) which returns true or false. This check may look up
I.sub.0 on access lists, check permission bits, or use some other
means of checking authorizations.
With the case of the simple RPC thus understood, the more complex
operations that are the subject of the present invention will now
be considered. These operations involve delegation of access rights
to intermediaries. With reference to FIG. 2B, suppose I.sub.0
requests some other process I.sub.1 to perform an operation on its
behalf. In this case, I.sub.0 is termed an initiator and I.sub.1 an
intermediary. According to the method of the present invention,
I.sub.0 creates an access control program P that specifies the set
of rights that it wishes to delegate to I.sub.1. The access control
program is a procedure that takes as parameters a caller, the
operation being performed, and the arguments to this operation, and
that returns an indication (e.g., true or false) of whether or not
the operation is allowed. After creating P, in a preferred
embodiment I.sub.0 digitally signs it with its digital signature,
thereby producing <P>.sup.I 0, which I.sub.0 includes in its
request to I.sub.1. (Digital signatures are known in the art and
are described, for example, in D. E. Denning, Cryptography and Data
Security, Reading, Mass.: Addison-Wesley Publishing Co., 1982.) The
meaning of <P>.sup.I 0 is "I.sub.0 authorizes anyone to make
requests on its behalf, as long as P approves each such request."
I.sub.1 then makes a request to S and transmits <P>.sup.I 0
along with the request.
The flowchart of FIG. 2C further illustrates the preceding steps,
as well as the steps executed thereafter by the server S. In step
250 I.sub.0 creates the ACP. In step 252 I.sub.0 digitally signs
the ACP to produce <P>.sup.I 0. In step 254 I.sub.0 issues
its request to I.sub.1 ; <P>.sup.I 0 is included in this
request. In step 256 I.sub.1 makes a request to S and transmits
<P>.sup.I 0 along with the request.
Before honoring the request, server S proceeds as follows:
1. In step 260 S verifies the identity of I.sub.1, the principal
making the request.
2. In step 262 S determines whether I.sub.0 has permission to make
this request. I.sub.0 cannot delegate rights it does not have. This
step can be carried out, for example, as a call to Check (I.sub.0,
op, object, . . . ).
3. In step 264 S verifies that P is correctly digitally signed by
I.sub.0.
4. In step 266 S determines whether I.sub.0 approves of the request
by executing P (I.sub.1 op, object, . . . ).
Thereafter, in step 268 S determines whether steps 260, 262, 264,
and 266 all have succeeded. If so, then execution proceeds at step
270, in which S executes the request. Otherwise execution proceeds
at step 275, in which access is denied and S refuses to execute the
request.
Steps 260 and 262 are the same as in the case of a no-intermediary
RPC such as that depicted in FIG. 1A with one important difference:
The access check in step 262 is based on the initiator I.sub.0
rather than the caller I.sub.1. Step 264 ensures that the
intermediary has not tried to acquire additional rights by
manufacturing a forged ACP or by tampering with an existing ACP.
Step 266 checks that this particular request meets the restrictions
imposed by I.sub.0 on I.sub.1 as specified in P.
The four checks of steps 260, 262, 264, and 266 are the only ones
required of the server. In particular, the server does not enforce
bounds on an ACP's lifetime or on who is permitted to use the ACP.
Because ACPs are programs, they can check these things themselves.
If an ACP is to remain valid for only a limited period of time,
then it can always return "access denied" if the current time is
greater than some built-in expiration date. If an initiator wishes
to delegate only to certain intermediaries, then its ACP can check
that the caller is one of the valid delegatees. By putting power
into the ACP, the delegation mechanisms are simplified.
The purpose of having I.sub.0 digitally sign the ACP is twofold.
First, the digital signature proves to the server that the ACP
being given to the server is the same ACP that was created and sent
by the initiator I.sub.0. Second, the digital signature proves that
the initiator I.sub.0, and not an impostor, actually created the
ACP. This twofold purpose can also be accomplished in ways other
than through the use of digital signatures. For example, in an
embodiment to be described below in which the invention is
incorporated in a modified version of the Andrew File System, an
authentication server is used. As another example, in some systems
in which a client, an intermediary, and a server execute on a
single node, the node's operating system provides adequate security
to ensure that the client's ACP is genuine, and no authentication
as such is required. These two examples by no means exhaust the
possibilities.
Deciding what operations to allow and disallow in an ACP requires
that the initiator know enough about the implementation of the
intermediary to give out the appropriate access rights. Note that
this is inherent to the tasks of restricted access delegation and
is not specific to ACPs. As an example, consider once again the
delegation chain illustrated in FIG. 2C. The operation that I.sub.0
requests of I.sub.1 need not be the same operation that I.sub.1
requests of S. Often, I.sub.1 will need to perform a series of
lower-level operations on S in the process of servicing I.sub.0 's
request. For example, I.sub.0 may instruct I.sub.1 to print a file
which resides on S. I.sub.1 may have to make a series of calls to S
in order to resolve the file's pathname, open the file, read it,
and finally close it. When I.sub.0 writes program P, it must be
aware of the operations that I.sub.1 will need to make to S since P
must be certain to grant these, and ideally only these operations.
A later section of this description tells how I.sub.0 can avoid
having to know I.sub.1 's implementation in some embodiments of the
present invention.
2.4 Programming language considerations
Many languages can be used for writing ACPs, ranging from
full-featured programming languages to non-procedural languages
that simply list patterns to match against the arguments. Any
Turing-complete language will suffice, and other languages can also
be suitable. Languages containing control constructs (e.g.,
conditional branching) are an interesting class because they enable
multiple possible paths of execution through an ACP.
Of the Turing-complete languages, simple interpreted languages such
as Lisp or Tcl (tool command language) are good candidates for
writing ACPs. These languages have successfully been used as
extension languages to augment the base functionality of various
programs. Because ACPs serve a similar purpose, namely, that of
extending the core set of access control concepts that a server
provides, they are likely to benefit from the same advantages these
languages have exhibited in other settings. An example of using
Lisp as an extension language is described in R. Stallman, GNU
Emacs Manual (Free Software Foundation, Oct. 1986); an example of
using Tcl as an extension language is described in J. K.
Ousterhout, "Tcl: An embeddable command language," Proceedings of
the USENIX Association 1990 Winter Conference (1990).
Where a general-purpose language is used for ACPs, a concern arises
with the safety of the server. A malicious or faulty ACP should be
prevented from corrupting the server or using excessive resources.
The server needs to be protected from program faults, such as NIL
pointer differences and division by zero, and needs to enforce
limits on CPU and storage use. One way to achieve this is to use a
carefully coded interpreter for the ACP language. When the
interpreter detects one of these conditions it aborts execution of
the ACP. If an ACP is aborted, then it is assumed to have returned
false, and the request is denied. Because ACPs are expected to be
relatively short, strict limits can be placed on them without
severely limiting their usefulness.
ACPs depend on access to request parameters and server state
information to implement their checks. A core set of information
that servers should provide in any ACP implementation includes the
requested action and its arguments, the authenticated identity of
the requestor, and the current time. Access to the requestor's
identity allows checks that restrict who may make the request, and
knowing the current time enables expiration checks. Provision of
the current time implies the need for globally synchronized clocks.
In practice this is not a problem since most modern distributed
systems already employ some form of clock synchronization.
Some clients may wish to specify access controls based on
additional information, such as the existence of files. Letting
ACPs examine any state in the server could violate security because
an ACP can transmit information to an intermediary via the success
or failure of the intermediary's server requests. A better model is
to allow an ACP to examine any state which the ACP author could
have examined through the normal server interface.
In some embodiments of the invention ACPs can also be allowed to
make changes to server state. Such a feature introduces a variety
of problems concerning resource management. For the most part, a
change to server state is preferably made by explicit request
rather than as a side effect of an access check. One notable
exception to this rule is described in the next section.
2.5 Revocation
The creator of a ACP may want the ability to unilaterally and
instantly revoke the rights granted by an ACP. The following is one
technique for ACP revocation. The initiator writes the ACP so that
the ACP checks for the existence of a revocation object, such as a
file, each time it is run. If the revocation object does not exist,
the request is denied. At the time the initiator creates the ACP,
it also designates the revocation object. When the initiator wishes
to revoke the delegated rights it simply eliminates the revocation
object. All subsequent requests from the intermediary will be
denied by the ACP. This revocation scheme requires no cooperation
from the intermediary. It also requires no involvement by the
server, except that the server must allow an ACP to inquire about
its associated revocation object, and in some embodiments, that the
server must create and destroy revocation objects at the
initiator's request.
An important question is where to store revocation objects. If an
ACP restricts access to one or more objects that reside on a single
server, then that server-or, more precisely, its associated stable
storage-is the ideal storage site for the ACP's revocation object.
The check for the existence of the revocation object can be done
locally by the server in this case. Things become more complex if
an ACP can be used on multiple servers. In this case, either the
ACP must be able to read a revocation object stored on a remote
server, or else the revocation object must be replicated across the
servers.
Another important question concerns how revocation objects are
designated. A straightforward scheme is to have the server create
revocation objects for each client upon the client's request. The
client can request creation of revocation objects at any time;
however, to avoid the overhead of repeatedly having to request
revocation objects, the client typically requests that a plurality
of revocation objects be created ahead of time, for example when
the client is initialized or reinitialized. These objects are then
available to the client for later use. The client maintains a
record of its revocation objects: which ones are in use in
connection with particular ACPs, which ones are free and available
for use with other ACPs, and which ones have been destroyed and are
thus no longer available. When the client wants to create a
revocable ACP, the client designates one or more of its free
revocation objects by associating these objects with particular
rights that are to be delegated in the ACP. The client includes
code in the ACP such that the delegation of a particular right or
rights in the ACP depends on the continued existence of the
designated revocation object or objects. The client also updates
its record of revocation objects to reflect the designation.
Still another important question concerns how revocation objects
are eliminated. Typically, the client eliminates a revocation
object in order to revoke the access right that is associated with
the revocation object and has previously been delegated in an ACP.
The client can also eliminate a revocation object for other
reasons, for example, if the client decides that the ACP is no
longer needed. Continuing the preceding straightforward scheme, to
eliminate a revocation object the client simply requests the server
to destroy the object. In response, the server authenticates the
client's identity to ensure that the client is not trying to
destroy someone else's revocation objects. Upon successful
authentication the server complies with the client's request and
destroys the revocation object. The client deletes the eliminated
object from its record of revocation objects.
By allowing clients to create revocation objects ahead of time, the
foregoing scheme for delegating and eliminating revocation objects
minimizes communication between client and server. It also
preserves an important advantage of the present invention, namely
that the client can specify at run time which intermediaries are to
have which access privileges and can do so without the need for
further interaction with the server. The exact implementation of
the scheme depends on the particular system in which the method of
the invention is embodied.
Other schemes to create, designate, eliminate, and destroy
revocation objects are within the scope of the invention. For
example, if a server can support only a limited number of
revocation objects, an allocation policy can be established to
determine how many revocation objects any given client can have
with respect to the server. Any of a number of such allocation
policies, including preallocation of all revocation objects among
clients, is possible. No matter what scheme is used, it is
important that revocation objects be stored in stable storage, so
that they are not inadvertently destroyed, for example through
server failures.
There can be as many revocation objects per ACP as is necessary to
carry out the purposes of the ACP. In particular, a single ACP can
be associated with multiple revocation objects in order to provide
for independent revocation of individual access rights with respect
to the same request. For example, suppose client C creates an ACP
that gives temporary read access to a first file called FILEONE and
temporary write access to a second file called FILETWO, both of
which are stored on file server S. If there are two revocation
objects, one for the access rights to FILEONE and one for the
access rights to FILETWO, the client can then, for example, revoke
an intermediary's permission to access FILETWO while still
permitting access to FILEONE. It does so by eliminating FILETWO's
associated revocation object.
FIG. 2D shows the steps involved in revoking access privileges
using revocation objects for another example involving FILEONE and
FILETWO in one embodiment of the invention. In this example the
client makes two requests of the server via the intermediary. The
first request concerns FILEONE and is to be executed immediately
while the second request concerns FILETWO and is to be delayed by
the intermediary. The client revokes the access privileges to
FILETWO before the end of the delay period, so that the second
request is partly denied by the server. It is to be understood that
this illustrative example concerns only one of the many situations
in which revocation objects can be used.
The steps of this example proceed as follows: It is assumed that a
number of revocation objects, including R1 and R2, have been
created ahead of time by client C at server S. In step 280 client C
designates revocation objects R1 and R2 that will correspond
respectively, to delegated access rights for FILEONE and FILETWO.
In step 282, the client creates the ACP. The ACP grants access
rights to FILEONE only for so long as the revocation object R1
continues to exist and to FILETWO only for so long as the
revocation object R2 continues to exist. In step 284 the client
issues a first request to the server via an intermediary I. This
request involves access to FILEONE. It is accompanied by the ACP.
In step 285 the client issues a second request that involves access
to FILETWO to the server via the same intermediary I. This request
is also accompanied by the ACP. The second request is a delayed
request, which the intermediary will not process until a specified
delay time elapses.
Next in step 286 the intermediary I, acting on the client's first
request, makes a request to the server S for access to FILEONE.
This service request is accompanied by the ACP. In step 288 server
S executes the ACP. In so doing, the server tests for the existence
of the revocation object R1 before granting access to FILEONE. If
the revocation object exists, the request is performed; otherwise
it is denied. At this stage of the example, both revocation objects
R1 and R2 exist, so the request for access to FILEONE is performed
in step 290.
Thereafter in step 291 the client eliminates the revocation object
R2, which corresponds to the access rights for FILETWO. In step 292
the delay time for the client's second request elapses. In step
293, the intermediary I, acting on the client's second request
after the elapse of the delay, makes a request to the server S for
access to FILETWO. This service request is accompanied by the ACP.
In step 294 server S executes the ACP. In so doing, the server
tests for the existence of the revocation object R2 before granting
access to FILETWO. At this stage of the example, R2 no longer
exists, so that the ACP returns false and the request for access to
FILETWO is denied in step 296.
An additional example, shown in FIGS. 2E and 2F, illustrates the
use of revocation objects in a situation in which a single client
request generates two intermediary requests. In FIG. 2E, client 300
is a user command process executing, for example, on a workstation.
Client 300 sends request 303 to compute server 305, asking compute
server 305 to compile source code file 311 which is stored on file
server 310. Request 303 has an access control program that
delegates to compute server 305 the rights to read source code file
311 and to write object code file 312, a version of which is
already stored on file server 312 at the beginning of this example.
These access rights depend respectively on the continued existence
of designated revocation objects 301 and 302. In response to client
request 303, compute server 305 will make two service requests to
file server 310. The first will be a request 306 to read source
code file 311 prior to compilation. The second will be a request
307 to write object code file 312 after compilation is
completed.
Next consider what happens if during compilation the user decides
that the compilation request was a mistake, and that compute server
305 must not be allowed to replace the existing version of the
object code file 312 with a newly compiled version. The user's
command process 300 eliminates the revocation object 307 by
requesting in request 315 that file server 310 destroy revocation
object 302. Thereafter, when compute server requests in request 307
to write object code file 312, the ACP returns false and request
307 is denied.
FIG. 2F flowcharts these steps in greater detail. In step 318 the
client designates revocation object R1, which corresponds to
revocation object 301 in FIG. 2E, as being associated with the
right to read source code file MYPROGRAM.C, which corresponds to
source code file 311 in FIG. 2E. Similarly, in step 320 the client
designates revocation object R2, which corresponds to revocation
object 302 in FIG. 2E, as being associated with the right to write
object code file MYPROGRAM.O, which corresponds to object code file
312 in FIG. 2E. In step 321 the client creates the ACP to delegate
rights to read MYPROGRAM.C and to write MYPROGRAM.O contingent upon
the continued existence of R1 and R2 respectively. In step 322 the
client issues its compilation request to the compute server,
accompanied by the ACP. In step 324 the compute server issues to
the file server a request, accompanied by the ACP, to read
MYPROGRAM.C. This request corresponds to request 306 in FIG. 2E. In
step 326, the file server executes the ACP. R1 exists and the ACP
returns true. In step 328, the file server grants read access to
MYPROGRAM.C to the compute server. In step 329 the compute server
proceeds to compile MYPROGRAM.C. In step 330, the user decides not
to compile after all, and accordingly the client eliminates
revocation object R2 in step 332 by requesting the file server to
destroy R2. In step 334 the file server complies with this request
and destroys R2. In step 336 the compute server finishes compiling
MYPROGRAM.C. In step 338 the compute server issues to the file
server a request, accompanied by the ACP, to write MYPROGRAM.O.
This request corresponds to request 307 in FIG. 2E. In step 340,
the file server executes the ACP. R2 no longer exists and the ACP
returns false. In step 342, the file server denies write access to
MYPROGRAM.O to the compute server. This completes the example.
If revocation is used often, special support for revocation objects
can be provided by servers. The revocation objects are cached in
memory to allow quick checks by the ACPs. The only operations on
the cached revocation objects are Create, TestForExistence, and
Destroy, which, respectively, create, test for the existence of,
and destroy the revocation objects. Only the TestForExistence
operation is available to the ACP itself.
Another form of revocation is "use-once" semantics in which an ACP
is automatically revoked after it is used, rather than being
available for reuse by the initiator. In the printer example given
earlier, suppose the initiator wishes that the printer only be
allowed to read the file to be printed once. This can be supported
by allowing ACPs to invoke the Destroy operation on its associated
revocation objects. While this violates the principle that ACPs
should be free of side-effects, permitting an ACP to destroy its
revocation objects can be considered safe enough and useful enough
to warrant an exception to the rule.
Still other revocation schemes are within the scope of the present
invention. For example, a revocation object could be a file that is
associated with multiple ACPs and that contains a list of tuples
(ACP, revocation status). To check for revocation in this scheme,
the ACP accesses its associated revocation object and determines
whether its status is revoked. In comparison with the
one-ACP-per-revocation-object scheme described above, this scheme
does not take full advantage of the fact that file servers
typically are optimized to check very rapidly for the existence of
files and are not optimized to search through data within
files.
2.6 Chained delegation
Now that the use of ACPs to delegate access rights to a single
intermediary has been described, next is considered the case of
cascaded delegation among multiple intermediaries. With reference
to FIG. 3A, after I.sub.0 has delegated rights to I.sub.1, I.sub.1
may wish to delegate some of these rights to a second intermediary,
I.sub.2. To do so, I.sub.1 writes a second ACP P.sub.1, digitally
signs it and sends both ACPs to I.sub.2. I.sub.2 presents both ACPs
to the server when it makes its request.
The flowchart of FIG. 3B further illustrates the preceding steps,
as well as the steps executed thereafter by the server S, for the
general case of n intermediaries. In step 350 I.sub.0 creates a
first ACP. In step 352 I.sub.0 digitally signs this ACP to produce
<P>.sup.I 0. In step 354 I.sub.0 issues its request to
I.sub.1 ; <P>.sup.I 0 is included in this request. Steps 355,
356, and 357 are then executed repeatedly for values of i from 1 to
n-1 inclusive. In step 355 I.sub.i creates an ith ACP. In step 356
I.sub.i digitally signs this ACP to produce <P>.sup.I i. In
step 357 I.sub.i issues its request to I.sub.i+1 ; all the ACPs
created so far, that is, <P>.sup.I 0 . . . <P>.sup.I i,
are included in this request. In step 358, I.sub.n issues a request
to S and transmits all the ACPs, that is, <P>.sup.I 0 . . .
<P>.sup.I i, along with the request.
When the server S receives this request, it must check, by calling
P.sub.0, that I.sub.0 has delegated rights to I.sub.1. Similarly,
by calling P.sub.1, S checks that I.sub.1 has delegated rights to
I.sub.2. In the general case, S has received a call from I.sub.n
along with n ACPs, <P.sub.0 >.sup.I 0, <P.sub.1 >.sup.I
1, . . . <P.sub.n-1 >.sup.I.sub.n- 1. It proceeds as
follows:
1. In step 360 S verifies the identity of In, the principal making
the request.
2. In step 362 S determines whether I.sub.0 has permission to make
this request. This is carried out, for example, as a call to Check
(I.sub.0, op, object, . . . ).
3. In step 364 S verifies that each P.sub.i is correctly signed by
I.sub.i.
4. In step 366, which is executed repeatedly n times, S verifies
that I.sub.i has delegated the required rights to I.sub.i+1 for
values of i ranging from 0 to n-1, viz:
S determines whether I.sub.0 approves of the request by calling
P.sub.0 (I.sub.1, op, object, . . . ).
S determines whether I.sub.1 approves of the request by calling
P.sub.1 (I.sub.2, op, object, . . . ).
. .
S determines whether I.sub.i approves of the request by calling Pi
(I.sub.i+1, op, object, . . . )
. .
S determines whether I.sub.n-1 approves of the request by calling
P.sub.n-1 (I.sub.n, op, object, . . . ).
Thereafter, in step 368 S determines whether steps 360, 362, 364,
and all executions of step 366 have succeeded. If so, S executes
the request in step 370. Otherwise execution proceeds at step 375,
in which access is denied and S refuses to execute the request.
The delegation of rights along the chain from intermediary to
intermediary can be represented by way of a formula. Let the
initiator's set of rights be denoted as R. The set R specifies what
operations the initiator is allowed to perform on which objects.
Let D(I.sub.i) denote the rights delegated by intermediary I.sub.i
via its ACP. D(I.sub.0) is the set of rights delegated by the
initiator's ACP. Then the general formula for the set of rights
obtained by the nth intermediary is
This formula says that the rights of intermediary I.sub.n are the
rights of the initiator as restricted by all the access control
programs of the intermediaries along the way (including the
initiator's).
Cascades of intermediaries can be more complex than the simple
chain described here. For example, the present invention
contemplates situations in which multiple intermediaries execute in
parallel as well as or in addition to a serial chain. Moreover, in
any situation involving a cascade of intermediaries, some or all of
the intermediaries can have revocation objects associated with
their ACPs. It will be appreciated that these example situations
are illustrative and are not intended to limit the invention's
scope.
3. A Specific Embodiment Using a Modified Version of the Andrew
File System
Files represent a type of object that is widely used and for which
access control is crucial. An embodiment of the present invention
has been built wherein ACPs have been integrated into a distributed
file system called the Andrew File System (AFS). Aspects of AFS
that are relevant to the present invention are described below. A
more complete description of AFS may be had by reference to the
article by J. Howard, M. Kazar, S. Menees, D. Nichols, M.
Satyanarayanan, R. Sidebotham, and M. West, "Scale and Performance
in a Distributed File System," ACM Transactions on Computer Systems
6(1):51-81, Feb. 1988. It is to be understood that ACPs according
to the method of the present invention find applicability with
other file systems besides AFS and with other types of servers
besides file servers.
The Appendix to this application shows the modifications made to
Andrew File System release 3 (as it appeared on the Aug. 19, 1990
Mt. Xinu release tape of the Mach operating system) and Tool
Command Language release 3.3 in order to produce the embodiment of
the present invention in the Andrew File System as described below.
More about the Appendix, including copyright information, is
discussed in the section "Software Appendix" that appears near the
beginning of this application.
3.1 Integrating ACPs into AFS
AFS is a distributed file system that operates in the context of
the Unix operating system. It allows for one or more file servers
and one or more clients. Each client and each server executes on
its own separate node. All the clients can communicate with all the
servers via a communications network. Clients can act as
intermediaries with respect to one another through the use of a
remote invocation facility, through which clients can execute Unix
commands on other clients.
AFS supports the caching of files, that is, the local copying by a
client of certain heavily used files that the client obtains from a
server. When a client finds a current copy of a file in its cache,
it is spared the overhead of having to go to the server to get the
file. AFS has a cache manager that maintains cache coherence; that
is, the cache manager ensures that a client gets the correct
version of a file and does not mistake an obsolete cached version
of the file for the current version. For example, suppose that file
FILEONE is on server S1. Client C1 reads FILEONE and caches it.
Thereafter client C2 writes a new version of FILEONE to server S1.
The next time client C1 reads FILEONE, AFS must ensure that C1
reads the new version of FILEONE from server S1 and ignores the
now-obsolete version of FILEONE stored in its cache.
In the prior art, AFS uses a combination of access control lists
and protection bits to control access to files. A variant of the
Kerberos protocol is used to authenticate clients. (A description
of the Kerberos protocol is found in J. G. Steiner, B. C. Newman,
and J. I. Schiller, "Kerberos: An Authentication Service for Open
Network Systems," in Proceedings of the Winter 1988 USENIX
Conference (Dallas, Tex., Feb. 1988) at 191-201.) The protocol that
AFS uses to authenticate clients in the prior art is as shown in
the flowchart of FIG. 4A: In step 410 a client I.sub.0 contacts an
authentication server AS. In step 412 the client I.sub.0 requests
from the authentication server AS an authentication ticket for
communicating with a file server S. This request is made on a
secure channel. (Secure channels are known in the prior art and are
described, for example, in Denning, Cryptography and Data Security,
supra.) In step 414 the authentication server AS creates a session
key K.sub.c. In step 416 the authentication server AS returns the
session key K.sub.c with a ticket that has been encrypted with the
file server's key K.sub.s. This ticket contains the session key
along with timeout information and I.sub.0 's identity.
In the specific embodiment of the present invention that will now
be described, the prior art AFS authentication protocol of FIG. 4A
is replaced by the protocol illustrated in the flowchart of FIG.
4B. The format of the authentication tickets used in AFS is
modified so that they can optionally include an ACP. To obtain such
a ticket, a client I.sub.0 proceeds as follows: In step 460, the
client I.sub.0 contacts an authentication server AS. In step 462
the client I.sub.0 requests from the authentication server AS
through a secure channel an authentication ticket for communicating
with a file server S. I.sub.0 sends an access control program P
along with the request to AS. In step 464 the authentication server
AS creates a session key K.sub.c. In step 466 the authentication
server AS returns the session key K.sub.c with a ticket that has
been encrypted with the file server's key K.sub.s. AS includes the
access control program P in this ticket. The ticket, when
transmitted to S, convinces S that AS believed I.sub.0 was the
author of P. This is the signature needed to convince S to use the
ACP.
Tickets in AFS are at most 2000 bytes long, which leaves room for
an ACP of approximately 1900 bytes in this embodiment. Variations
of the embodiment can accommodate larger ACPs through more
substantial changes to the AFS protocol. There is an advantage,
however, to keeping ACPs short, namely, that short ACPs are less
apt to contain programming bugs than are longer ACPs, and are
therefore more likely to be trustworthy. With short ACPs, the
initiator minimizes the possibility that it will inadvertently give
away to intermediaries any access rights other than the ones it
intends to give away.
Aside from generating ACPs and including them in requests to the
authentication server, no changes are made to the AFS client in
this embodiment of the invention. When the AFS client obtains a
ticket from the AS, the client passes the ticket to a server along
with a file system request in the usual manner. When a server
receives a request that includes an ACP, it interprets the ACP to
determine whether or not to grant the request.
The specific embodiment permits ACPs to be used in conjunction with
the existing remote invocation facility of AFS. This facility,
which is a modified version of the Unix rsh (remote shell) command,
executes an arbitrary Unix command on another workstation. FIG. 4C
illustrates an interaction in which an AFS client, I.sub.0, uses
the remote invocation facility to run some command on intermediary
I.sub.1. When the intermediary contacts the server, it presents the
ticket containing the ACP. The server treats this as though the
initiator had made the connection, but restricts access as
specified by the ACP.
The specific embodiment of the present invention in AFS affords
increased security over the unmodified AFS system. AFS's version of
rsh simply passes the user's authentication ticket and session key
to the intermediary in the clear. The intermediary, as well as an
intruder eavesdropping on the net, can use the ticket to obtain the
full rights of the initiator. With ACPs, these rights can be
restricted and given short expiration times.
Variations on the specific embodiment can provide still more
security by incorporating means whereby the server can
independently authenticate the intermediary. For example, in one
such variation the server is passed two authentication tickets, one
for the initiator, which contains the ACP, and one for the
intermediary. This provides additional security because the ACPs
can discriminate based on the identity of the intermediary.
The specific embodiment permits an intermediary to receive or
modify only data for which at least one of the client's users has
access. For example, if the client is a workstation, at least one
of the workstation's users must have access to the data. The
embodiment does not ensure that data belonging to an individual
user of the workstation is protected against unauthorized access by
another user of the same workstation. This follows from the
operation of the AFS cache manager at the workstation. Because a
workstation can be used by more than one user, the AFS cache
manager duplicates the permission checks that the file server
performs. This prevents a user from reading a file for which he has
no access rights but that is in the cache due to another user on
the same workstation. However, the intra-workstation security check
sometimes fails to protect data properly. Variations on the
embodiment can incorporate changes to the cache manager to ensure
data protection for each individual user.
3.2 An ACP language
The specific embodiment of the invention in AFS uses Tcl as the
language for writing ACPs. Tcl is suitable because it has a small
re-entrant interpreter. Although Tcl delivers adequate performance,
the Tcl interpreter is not optimized for speed. Other languages
having faster interpreters can be used in variations of the
specific embodiment. Lisp is one possibility. The GNU Emacs Lisp
interpreter (described in R. Stallman, GNU Emacs Manual, supra) is
3-50 times faster than the Tcl interpreter, depending on the mix of
integer and string operations.
ACPs written in Tcl cannot make calls on the file system or modify
the state of the server in any way. Nevertheless, they do have
access to some information in addition to the requested operation
and its actual parameters. This information includes a
classification of the request as to whether it reads or writes
data, the parent directory of the file being operated upon, and the
current time. The classification information simplifies ACPs since
they need not list all possible operations. The parent directory
makes it convenient to write ACPs that restrict access to a single
directory.
The embodiment incorporates a few changes made to the Tcl
interpreter to protect the server from malicious or faulty ACPs.
These changes include a bound on the number of Tcl statements that
can be executed in an ACP, a bound on the amount of storage an ACP
can allocate, and a bound on recursion depth. If an ACP exceeds any
of these bounds, then it is terminated and treated as though it
returned false, i.e., access is denied.
Following is a source code listing for a sample ACP written in Tcl
that a user might want to use within the specific embodiment:
______________________________________ /*Example 1*/ expr { [string
compare $opclass "fetch"] == 0 && [string compare $filename
"/user/joe/paper.ps"] == 0 && [string compare $caller
"fred"] == 0 } ______________________________________
The user would intend the program to allow read access by user
"fred" to a single file, "/user/joe/paper.ps". Although the program
appears at first to be a reasonable ACP, it does not actually work
in this embodiment. The reasons that it does not work are described
in the next section.
3.3 Problems encountered in practice
Three major problems prevent users from writing simple ACPs like
that presented in the preceding source code listing. Although these
problems are specific to AFS, they are worth discussing since they
are representative of the types of difficulties that can be
encountered in integrating ACPs into existing systems.
First, an intermediary does not have an identity of its own. The
AFS designers decided to avoid the substantial administrative
overhead that would be entailed in establishing identities for all
workstations and in handling key distribution and protection. This
is not unusual in existing systems. Therefore, even in a variation
on the specific embodiment in which authentication tickets can be
passed to the server as described above, the server cannot require
an authentication ticket from the intermediary. Thus, an ACP cannot
check the identity of the intermediary.
Second, file servers in systems like AFS or NFS employ unique
object identifiers (ids) instead of human-readable names in most of
their access requests. ACPs must refer to these file identifiers.
This requirement makes it substantially harder for humans to write
ACPs than would be the case if the ACPs could refer to
human-readable names. Moreover, this requirement prevents ACPs from
checking whether a file name matches some pattern. For example, it
may be desirable for an ACP to grant access to files having names
of the form "*.o," where "*" is a wildcard, but not to files having
names of the form "*.c." This is not possible in the specific
embodiment since ACPs are passed file ids rather than names. A
variation of the specific embodiment can be constructed in which
the server provides a mapping from object id to the appropriate
human-readable name for an object. However, the human-readable name
for an object may not be unique since AFS allows symbolic links,
that is, indirect references to files by means of human-readable
names that point directly or indirectly to actual file identifiers.
In this case the server must take care to map the object id to the
appropriate name, probably the name under which a file was opened.
Depending on the server, the information needed to decide which
mapping to use may or may not be available at the time an access
request is made.
Third, AFS clients are responsible for resolving a file's pathname.
Each of the directories from the root of the file system to the
file name must be retrieved by the client workstation. Thus, an ACP
that wants to delegate read access to an individual file must also
give read permission to the directories in the file's pathname.
Following is a source code listing for a valid ACP that provides
read access to file "/user/joe/paper.ps":
______________________________________ /*Example 2*/ expr { [string
compare $opclass "fetch"] ==0 && ([string compare $fid
"20000012 00000d24 00001a8d"] == 0 .parallel. [string compare $fid
"20000001 00000001 00000032"] == 0 .parallel. [string compare $fid
"2000000a 00000e30 000024c2"] == 0 .parallel. [string compare $fid
"20000012 00001b65 00000092"] == 0 }
______________________________________
In this program, the file id for "paper.ps" is "20000012 00000d24
00001a8d". The ACP also includes the file ids for the "/", "user"
and "joe" directories This ACP, which has the same intended effect
as the nonworking one introduced above, works properly and actually
can be used within the specific embodiment of the present invention
in AFS.
Users may find it cumbersome to write ACPs like that presented in
the previous program (Example 2). A tool that automatically
converts an ACP like the one in Example i to one like Example 2 is
thus desirable. Such a tool is outlined in a later section.
3.4 Performance
To determine the overhead of using ACPs in the specific embodiment,
some simple experiments were performed. The first experiment
consisted of measuring the elapsed time for a stat system call
under various conditions. stat is a Unix command that returns
information about a file, such as the file's owner, length and
modification date. The stat system call causes the AFS client to
make a FetchStatus RPC to the server to fetch a block of
information about a file including such information as the owner,
length, and modification date. FetchStatus is an AFS command that a
client uses when synchronizing its cache. FetchStatus sends a
message from the client to the server on which the file is stored.
The server responds by providing the client with the file's owner,
length, and modification date. The client uses this result to
determine whether its cached version of the file is obsolete.
Three cases were tested. In the first case no ACP is supplied with
the stat call. In this case, the modifications to the AFS server
have a negligible performance impact. In the second case, an ACP is
supplied that always returns true. In the third case, an ACP is
supplied that restricts writing to a particular directory. The
source code listing for the ACP used in this third case is as
follows:
______________________________________ /*ACP for third test case */
expr { ( [string compare $filetype "dir"] == 0 && [string
compare $fid "20000012 0000009d 00001a3a"] == 0)
.parallel..parallel.[string compare $parentfid "20000012 0000009d
00001a3a"] == 0 .parallel..parallel.[string compare $opclass
"fetch"] == 0 } ______________________________________
This ACP allows changes to the directory (first clause), changes to
files within the directory (second clause), and reads to any other
files (third clause). In the test, the files referenced by the stat
calls were not in the directory named by the ACP, so the ACP did
three string comparisons.
The test configuration comprised a Sun 4/110 running the AFS file
server code and a Sun SparcStation 2 running the client code. The
4/110 is roughly half the speed of the SparcStation 2. The results
of running the test are shown in Table 1.
TABLE 1 ______________________________________ Elapsed times for
stat call under various conditions. Test Case Execution Time
______________________________________ No ACP 7.7 ms ACP that
returns "true" 9.5 ms ACP in FIG. 7 12.8 ms
______________________________________
4. Coping with ACP Complexity
The general nature of ACPs makes them both powerful and dangerous.
A simple coding bug can grant undesired access rights, possibly for
an unbounded length of time. The complexity of creating the desired
correct ACP can be addressed in at least two ways: ACP language
support and the provision of ACP templates.
A first approach to controlling complexity is through the
incorporation of default provisions into ACPs. A variety of default
provisions are desirable in most or even all ACPs. These include
expiration times, intended users, and intended access scope. Rather
than forcing ACP writers to specify these checks procedurally in
each ACP, the ACP language can provide a declarative section in
which the relevant values can be succinctly specified, with
appropriate default values being supplied in their absence.
A second approach to controlling complexity is to place the burden
of generating correct ACPs on the application and server writers
instead of the application user. The application writer is more
likely than the user to know the implementation details of the
intermediary, and hence to know which access rights need to be
delegated. This second approach, then, assumes that the application
and server writers can be trusted to provide safe ACPs and that the
principal culprits to safeguard against are individual instances of
machines or services claiming to be something that they are
not.
The print program described earlier serves as an example of this
second approach. The publicly available print software (stored on a
safe file server) is responsible for generating an ACP that grants
access only to the file to be printed. The application writer can
generate ACPs by providing a template that instantiates into a
specific ACP at runtime. This template consists of an ACP that is
written in advance by the application author, with slots to be
filled in with usage parameters. The print ACP template can itself
employ lower level templates provided by the file servers it knows
about. Some example templates are:
ReadOneFile(name, lifetime, user)
restrict reading to the file given by name; access may only be by
user and must occur before lifetime. Both lifetime and user can
have default values
ReadOnly(lifetime, user)
restrict rights to the user's read rights.
WriteInDir(directory, lifetime, user)
restrict writing to a single directory
When one of these is instantiated, it becomes an ACP with the
arguments hard-coded in.
5. Additional Aspects of the Invention
Several additional aspects of the invention will now be presented.
These aspects are presented by way of illustration and are in no
way intended to limit the scope of the invention.
ACPs according to the method of the present invention are useful
for delegation in other settings beyond the context of distributed
systems. One such setting is a system in which client and server
are processes running on the same computer or workstation rather
than on two or more physically separate computers. For example,
consider a workstation user that has just received a large program
from a mailing list and wants to run that program. The user is not
completely sure he can trust this software; for example, the user
is concerned that the software may be infected by a software virus,
or that it may attempt to execute another program without the
user's knowledge. However, the user knows which files the software
should write and execute if it works correctly. According to the
method of the present invention, the user creates an ACP and
attaches it to an invocation of the program. In this aspect of the
invention, the initiator is the user's command processor, the
intermediary is the untrusted software, and the server is the local
operating system. Because the ACPs can be managed securely by the
operating system, digital signatures are not required.
Another example of the use of ACPs in a nondistributed system
concerns setuid programs. Many operating systems have a facility
that allows a user to delegate his rights to a program known as a
setuid program. When the setuid program runs, it executes with the
rights of the owner of the program file instead of the rights of
the invoker. A typical Unix system, for example, has many of these
programs that run as the so-called super-user, who has unlimited
access rights. Bugs in these setuid programs are a major source of
security weaknesses. A malicious user can exploit a bug in such a
program to cause it to read, modify, or execute some file that the
program author did not intend it to reference.
An ACP attached to a setuid program can limit the damage caused by
a bug therein. In principle, the attachment of the ACP provides no
additional protection since the system administrator is responsible
for both the setuid program and the ACP. In practice, however, the
ACP can be made much simpler than the setuid program. This
simplicity can give the system administrator confidence that the
combination of the setuid program and the ACP is less likely to
have a damaging bug than the setuid program alone.
ACPs can be used to provide a limited form of setuid functionality
in a distributed system. A game program running in a distributed
system can have an embedded ACP that allows any user to modify the
high score file. When the game wishes to modify the score file, it
uses this ACP, running as whoever invoked the game. In principle,
an intruder could look in the program, decode it, and extract the
ACP. But if he did, all the intruder would get would be the ability
to modify the high score file for this particular game. The
alternative for a network setuid facility would be to encode
something equivalent to the author's full rights, such as his
password, in the program. Use of the ACP limits the damage if the
program is decoded. For certain applications, this can provide
adequate security.
6. Conclusion
Access control programs (ACPs) permit controlled delegation of
access rights to untrusted computer hosts. If an initiator of an
action does not fully trust an intermediary, then it can create an
ACP and pass it to the intermediary. The ACP is executed at a
server for each request made by the untrusted intermediary and
decides whether or not to allow the request. An ACP cannot grant
rights that its creator did not possess; it can only restrict these
rights.
ACPs can be incorporated into current systems to augment such
systems' existing access control facilities. Typically this
incorporation requires only digital signatures, two-party
authentication, and an interpreter for the ACP language. The exact
implementation in each case depends on the specifics of the
underlying system. One of the strengths of the ACP design is that
it places no assumption on the type of access control provided by
the system or on the authentication protocol employed. ACPs can be
used with both public and private-key based security
mechanisms.
All decisions about the rights delegated by an ACP are incorporated
into the ACP itself, including who is allowed to use the ACP and
for how long. Because ACPs bear the power of a full programming
language, a wide range of access control policies can be
implemented by clients without the involvement of servers. Because
ACPs are fully contained and digitally signed, they can be freely
passed around. Typically, a client will pass an ACP along with an
operation request or with a connection setup request. However, ACPs
can also be published, in which case, a request need only identify
which ACP authorizes it.
The power of ACPs must be used carefully. In particular, servers
must protect themselves from malicious or buggy ACPs. Creators of
ACPs must take care to avoid inadvertently delegating excessive
rights. Servers can protect themselves by using a carefully coded
interpreter. The use of templates and ACP language defaults as
described above can aid the construction of correct ACPs.
A general problem of restricted delegation is that the initiator
must know enough about the implementation of the intermediary to
delegate the appropriate set of access rights. Clients tend to
think in terms of high-level operations, such as "print this file",
while the accesses made by intermediaries to servers involve
lower-level operations, such as "stat this directory then retrieve
the file with this unique ID." ACP translation tools-that is,
software tools that translate an ACP program expressed in a form
convenient for the programmer into an ACP program expressed in a
form usable by the server-can be written to provide help in coping
with this problem.
Although the above is a complete description of certain embodiments
and aspects of the invention, various alternatives, modifications,
and equivalents can be used. Therefore, the above description
should not be taken as limiting the scope of the invention. Rather,
the scope of the invention is defined by the appended claims along
with the full scope of equivalents to which these claims are
entitled. ##SPC1##
* * * * *