METHOD AND APPARATUS FOR PROVIDING SECURITY FOR SERVERS EXECUTING APPLICATION PROGRAMS RECEIVED VIA A NETWORK

Abstract: A method and apparatus for providing security to a server running an application program received over a network is provided. The application program, along with a source identifier is received from a source computer. Access privileges to server resources are granted based on the source identifier. The application program is loaded into a predetermined, bounded region of memory.

Description: METHOD AND APPARATUS FOR PROVIDING SECURITY FOR SERVERS EXECUTING APPLICATION PROGRAMS RECEIVED VIA A NETWORK FIELD OF THE INVENTION The present invention relates to network computing, and more specifically, to providing security for servers that receive applications programs via a network. BACKGROUND OF THE INVENTION Currently, the largest computer network in existence is the Internet, which is a worldwide interconnection of computer networks that communicate using a common protocol. The Internet grew out of work funded in the 1960s by the United States Department of Defense's Advanced Research Projects Agency (ARPA). Millions of computers, from low end personal computers to high-end super computers are connected to the Internet. For many years, few outside of the academic /research community accessed the Internet. In 1989, a new type of information system known as the World-Wide Web (the Web) was introduced to the Internet. Early development of the Web took place at CERN, the European Particle Physics Laboratory. The Web is a wide-area hypermedia information retrieval system. In 1993, the National Center for Supercomputing Applications (NSCA) released a Web browser called "Mosiac" that implemented a graphical user interface (GUI). Mosiac's GUI was simple to learn and allowed users to retrieve documents from the Web using simple point-and- click commands. The introduction of Mosaic simplified document and information retrieval over the Internet and more specifically on the Web. As a result, use of the Internet became more popular outside of the academic /research community. At that time, architecture of the Web typically followed a conventional client-server model. The terms "client" and "server" are used to refer to a computer's general role as a requester of data (the client) or provider of data (the server). In the Web environment, Web browsers, such as Mosaic, reside in clients and Web documents reside in servers. Web clients and Web servers communicate using a protocol called "Hyper Text Transfer Protocol" (HTTP). A browser opens a connection to a server and initiates a request for a document. The server delivers the requested document, typically in the form of a text document coded in a standard HyperText Markup Language (HTML) format. In 1994, a subsidiary of Sun Microsystems released a Web browser based on a programming language developed at Sun called Java™. Programs written in Java are architecture neutral such that the programs run on any platform that supports Java. The programs are architecture neutral because they are compiled into a series of byte-codes that are not hardware specific and thus can be downloaded and executed on many different computers. Byte-codes are transmitted over the Internet and then translated and executed by the receiving computer. One unique feature of Java not provided by typical Web browsers is an ability to provide applets as part of a Web page. Applets are part of a Web page, but they are downloaded and executed by the computer running a Web browser rather than the Web server. Thus, a user, with a browser that supports Java, accesses a Web page and downloads a small program that is executed locally. This, however, presents security issues not present in the traditional client-server model. To provide security, Java methods and variables are accessed by name and are executed in a restricted environment that includes a predetermined portion of memory. Furthermore, when byte-codes are received they are subjected to a verification process that determines whether the byte-codes have been modified. Security for applets may be provided in a straightforward all-or- nothing manner. For example, the applet is loaded and executed, or it is not loaded and executed. Because the applet is self-contained, it does not access local resources other than a designated, bounded region of memory. Another unique feature of Java is the servlet, which is a program, like an applet, however, a servlet runs on the Web server rather than the Web browser. Servlets are typically larger than applets and /or require more resources. For example, a servlet may be a search program offered by a particular server. A user accesses the servlet by supplying search parameters. The servlet then executes a search of resources available to the server. Thus, a user may have access to certain server resources and the server may have its search software updated by a third party without any effort by the server administrator. Because servlets may require access to server resources, the all-or- nothing approach is inefficient. In order to provide a secure all-or-nothing scheme in a server that loads servlets, a standard subset of resources would be offered to all servlets. However, different servlets require different resources and different servlet sources may be worthy of different levels of trust. Thus, prior security schemes do not provide a flexible, yet secure, environment for providing servlets on a server. Therefore, it would be desirable to provide security to Web servers from potentially hostile programs, wherein permissions to access the resources of the server are granted based on the source of the program. As the Web grows, it would be desirable to provide greater access to the resources and features of the Web. Thus, many controllers of Web servers may wish to provide access to servlets developed by third parties. Therefore, it would be desirable to provide security to Web servers from potentially hostile servlets, wherein access to the resources of the server are allocated based on the source of a particular servlet. SUMMARY OF THE INVENTION A method and apparatus for providing security for a server executing programs received by the server via a network is disclosed. An application program that is to be provided by a Web server along with a source identifier is received by the Web server via a network, such as the Internet. Before loading the application program, the server performs a verification procedure including granting access privileges based on the source identifier. Access privileges are granted or withheld for a plurality of resources available to the server. If an application program is received from a known hostile source or no access privileges are granted, the applications program may be rejected. Thus, the resources defining the application program's universe, or sandbox, is determined individually based on source identifiers. BRIEF DESCRIPTION OF THE DRAWINGS The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which: Figure 1 is one embodiment of a network that may be used to practice the present invention. Figure 2 is a block diagram for practicing the present invention. Figure 3 is a flow diagram of one embodiment of verifying a servlet and allocating resources to the servlet based on the source of the servlet according to the present invention. DETAILED DESCRIPTION A method and apparatus for providing security to servers running applications programs based on the source of the application program is described. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention. An application program that is to be provided by a Web server along with a source identifier is received by the Web server via a network, such as, the Internet. Before loading the application program, the server performs a verification procedure including granting access privileges based on the source identifier. Access privileges are granted or withheld for resources available to the server. If an application program is received from a known hostile source, or if no access privileges are granted, the applications program may be rejected. Thus, the resources defining the application program's universe, or sandbox, are determined individually based on source identifiers. Figure 1 is one embodiment of a network that may be used to practice the present invention. Internet 100 connects a plurality of hosts, such as hosts 120, 122, 124 and 126 to Web server 150. The hosts may also act as Web servers to provide files or resources to other hosts. Alternatively, Internet 100 may be a local area network (LAN) or other network that connects a plurality of computers together. According to the present invention, a host may send a program, such as a servlet, to Web server 150. When Web server 150 receives a servlet and a source identifier from a source computer, the source of the servlet is checked to determine the access privileges available to the servlet. Thus, Web server 150 may reject a servlet from an unknown or known hostile source, or Web server 150 may accept and load a servlet and grant access to server resources based on the source of the servlet. Once the servlet is loaded by web server 150, it may be accessed by a web browser running on a host connected to web server 150. Figure 2 is one embodiment of a source computer coupled to a Web server via the Internet according to the present invention. The steps that for providing security in the server according to one embodiment are show as blocks in the computer that performs that step. An application program, such as a servlet, may be developed on a computer other than the one on which it is to be offered over a network. A servlet is written in servlet code, shown by 202. According to one embodiment, the servlet is developed in a Java environment, however, a servlet or other program may be developed in a non-Java environment. The servlet code is compiled, at 204, into a plurality of byte codes, shown by 206. Byte-codes are similar to machine instructions, however, they are not machine specific. Byte-length codes are used in one embodiment of the present invention, however, other code sizes may also be used. It is important to note that all of the codes are the same size. A digital certificate, which includes a digital signature, represented by 208, is then appended to byte-codes 206. According to one embodiment, the digital certificate is an X.509 certificate. However, other source identifiers may also be used. The source identifier must provide a secure and unique identification of the signer such that the administrator of the receiving web server may trust the source identifier to authenticate the source of the servlet. The byte-codes are sent to a designated server via the Internet 100, or other network. The receiving computer, such as Web server 150 that receives the byte-codes executes a verification process 252. Verification comprises examining the source identifier, such as digital certificate 208, to a local list of known trusted sources and granting resource privileges based on that source identifier. Additionally, the verification process includes other verification techniques to determine whether the byte-codes have been modified or if the source identifier has been modified. According to one embodiment, an access control list (ACL) is maintained on Web server 150 that stores trusted sources and the privileges extended to servlets received from those sources. Resource privileges include load privileges, permission to read or to write files on the server's disk(s), network read and write privileges, execution privileges, system property access, and socket listen or connect privileges. Other privileges may also be granted. Any combination of one or more of these access privileges may be granted to a servlet. Once the byte-codes have been verified, they are translated into servlets configured to run on the architecture of Web server 150. The servlet is then loaded into the servlet's sandbox (i.e., a known, bounded area in memory and granted access only to those specific resources listed in the ACL). Once the servlet is loaded in Web server 150, Web browser 170 may access the servlet and any resources available to the servlet. Thus, resource privileges are granted on a servlet-by-servlet basis, which increases the flexibility of a Web server's security. This improved flexibility allows administrators to grant more privileges to known and trusted sources, while granting fewer privileges to new or unknown sources. By eliminating an all-or-nothing security approach, the web may offer more resources in a more convenient manner. Figure 3 is a flow diagram of one embodiment of verifying a servlet and allocating resources to the servlet based on the source of the servlet according to the present invention. In step 300, a Web server receives a servlet or other application program via a network, such as the Internet. In step 310 the local ACL is checked to determine what, if any, privileges are to be granted to the servlet based on the source identifier received with the servlet. The ACL may contain an entry for unsigned servlets to grant a specified level of access to all unsigned servlets. The Web server may also reject all unsigned servlets along with servlets received from a source known to be hostile. If no access privileges are granted in step 320, the servlet is rejected or not loaded in step 330. If the servlet is granted access privileges in step 320, a sandbox is defined for the servlet in step 340. A sandbox defines the set of access privileges granted to the servlet. In step 350, the servlet is loaded by Web server 150. In addition to limitations imposed on a servlet by the sandbox to which it is assigned, other checks may be performed. For example, accesses to certain resources may be monitored by the server to guard against hostile behavior. Thus, by providing identity-based access controls, a Web server can control which servlets have access to which data. This arrangement provides protection against theft or alteration of data. In addition, by restricting a servlet to a sandbox, the Web server can control the damage that malicious code can cause. In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

Claims: CLAIMS What is claimed is: 1. A method for providing security for a server running an application program comprising the steps of: receiving the application program from a source computer, wherein the application program has associated with it a source identifier that uniquely identifies the source computer in a secure manner; determining resources to be provided for use by the application program based on the source identifier; granting access privileges to the resources determined to be accessible by the application program; and loading the application program into a predetermined, bounded location in memory of the server. 2. The method of claim 1, wherein the source identifier is a digital signature. 3. The method of claim 1, wherein the step of determining comprises the step of checking an access control list (ACL) to determine the resources available to the application program based on the source identifier. The method of claim 1, wherein the access privileges comprise: server disk read privileges; server disk write privileges; server network read privileges; and server network write privileges. 5. The method of claim 1, wherein the access privileges comprise: execution privileges; system property access privileges; socket connect privileges; and socket listen privileges. 6. The method of claim 1, wherein the application program is received from the source computer the Internet. 7. The method of claim 6, wherein the application program is received via the world wide web. 8. The method of claim 1, wherein the application program is received a local area network. 9. A method for providing an application program for execution on a remote server, wherein the server executes the application program in a bounded range of memory locations and allocates local resource access based on a source of the application program comprising the steps of: generating the application program; compiling the application program into a plurality of predetermined length codes; generating a source identifier; associating the source identifier with the codes; and sending the codes to a server, wherein the server verifies the codes and allocates access to local resources based on the source identifier, further wherein the server generates the application program based on the codes received. 10. The method of claim 9, wherein the source identifier comprises a digital signature. 11. The method of claim 9, wherein the plurality of predetermined length codes comprises a plurality of byte-length codes. 12. The method of claim 9, wherein the resources allocated comprise: server disk read privileges; server disk write privileges; server network read privileges; and server network write privileges. 13. The method of claim 9, wherein the resources allocated comprise: execution privileges; system property access privileges; socket connect privileges; and socket listen privileges. 14. The method of claim 9, wherein the codes are sent via the Internet. 15. The method of claim 9, wherein the codes are sent via a local area network. 16. An apparatus for loading an application program received from a source computer for use on a server comprising: means for receiving the application program from a source computer, wherein the application program has associated with it a source identifier that uniquely identifies the source computer in a secure manner; means for determining resources accessible by the server to be provided for use by the application program based on the source identifier; means for granting access privileges to the resources determined to be accessible by the application program; and means for loading the application program into a predetermined, bounded location in memory of the server. 17. The apparatus of claim 16, wherein the source identifier comprises a digital signature. 18. The apparatus of claim 17, wherein the means for determining resources accessible by the server comprises an access control list (ACL) maintained on the server. 19. A machine readable medium having stored thereon data representing sequences of instructions, which when executed by a computer system, cause said computer system to perform the steps of: receiving the application program from a source computer, wherein the application program has associated with it a source identifier that uniquely identifies the source computer in a secure manner; determining resources accessible by the server to be provided for use by the application program based on the source identifier; granting access privileges to the resources determined to be accessible by the application program; and loading the application program into a predetermined, bounded location in memory of the server. 20. The machine readable medium of claim 19, wherein the source identifier comprises a digital signature. 21. The machine readable medium of claim 19, wherein the step of determining comprises the step of checking an access control list (all) to determine the resources available to the application program based on the source identifier. 22. The machine readable medium of claim 19, wherein the access privileges comprise: server disk read privileges; server disk write privileges; server network read privileges; and server network write privileges. 23. The machine readable medium of claim 19, wherein the access privileges comprise: execution privileges; system property access privileges; socket connect privileges; and socket listen privileges.

Inventors: DHARMARAJ SATISH K, LEE JOHN Y, DHARMARAJ, SATISH, K., LEE, JOHN, Y.
Applicants: SUN MICROSYSTEMS INC, SUN MICROSYSTEMS, INC.
Application year: 1998
Main classification: G06F1
IPC codes: G06F1, G06F9, G06F12, G06F13, G06F21