Client security for networked applications

[0001] This application is a continuation of and claims the benefit of priority to U.S. patent application Ser. No. 09/374,574, filed on Aug. 13, 1999, now U.S. Pat. No. 6,775,783, entitled “Client Security for Networked Applications”, naming Jonathan T. Trostle as the inventor, the contents of which are incorporated herein by reference in its entirety for all purposes.

[0002] The present invention relates to computer security systems for networked applications. More specifically, the present invention relates to limiting access by one or more users to networked applications.

[0003] Most computer systems currently in place are used by multiple users in parallel and/or serially. This includes networked computer systems that have two or more of computer processors, storage units, and/or other computer hardware, some of which can include various computer software. In addition to limiting access to the computer system itself, it is sometimes desirable for different users to have different rights or access to various applications or services on the network (“network services”). Such access control may be useful to maintain the integrity of the computer system, including that of resident data or programs. Such needs can become increasingly important and their solutions more complex as the number of users and/or size of the network increases.

[0004] Access to an application server or particular use of an application server can be limited by the application server requiring permission information associated with the application and the user invoking the application client. When the user invokes the application client, the permission information is passed to the application server. The application server evaluates the permission information to determine whether and/or how to proceed with the server functions. For example, in a web browser application, when the web browser client is invoked to access a requested URL via the web browser server, the permission information related to the user and the web browser client are passed to and used by the web browser server. The web browser server can use the permission information to make access control decisions, e.g., by evaluating whether the user has the permissions that are appropriate for accessing the requested URL. It can be appreciated, therefore, that when permission information associated with a first user is used by an application client when invoked by a second user, the second user may masquerade as the first user and gain access to information for which that second user does not have rights. Depending upon the permission information, the second user may be able to read, write, execute, or perform some other process with regard to information, when the second user does not have such predetermined rights.

[0005] Permission information or information from which the permission information can be determined, collectively called access information, can be stored in an access file in memory of the host computer system. Typically, an individual host computer of a computer network includes an operating system which can facilitate control of the host file system of files, including the access file. The file system can maintain the file permissions or access control lists (ACL's) of the various files located in memory of the host. Usually these permissions can be modified by the owner of the file or by another entity with appropriate rights. More particularly, such permissions and ACL's can include an identification of the user(s) that have permission to, for example, write to and/or read from the particular file. Thus, the file system can provide a measure of access control for such files under its purview. However, with some operating systems, techniques can be used by a user to gain access to the access file, and therefore to permission information, associated with any other user. Such users can then masquerade as other users and gain unauthorized access to information.

[0006] Accordingly, a security system and method is desired to provide increased access control to network applications and/or services by more effectively controlling access to network security credentials that allow users to authenticate to application servers. It is also desired to extend such access control to a per-process granularity on the user host computer system. In particular, it is desired that such security system require minimal complexity and minimal amount of change to an existing computer system, while maximizing allowable user access and access control flexibility. Such a system and method are implemented in conjunction with an operating system with which each process is prevented from accessing the memory associated with the operating system and the memory associated with other processes on the host computer system.

[0007] The foregoing and other needs that will become apparent from the following description, are achieved by the present invention which comprises, in one aspect, a computer-implemented method of limiting access to a credential that can facilitate access by a first user to a computer networked service on a networked computer system. The method includes receiving user information provided by the first user and storing the credential such that the credential is accessible only by using a local security authority. The method also includes generating a random secret value corresponding to the credential, and storing the random secret value in a secret file that can be modified and retrieved only by the first user.

[0008] In another embodiment, a computer readable medium containing program instructions for limiting access to a credential that can facilitate access by a first user to a computer networked service on a networked computer system, wherein when the computer readable medium is read by a computer system having a processor and memory the program instructions are configured to be executed by the processor. The computer readable medium includes program instructions for recognizing user information provided by the first user and program instructions for storing the credential such that the credential is accessible only by using a local security authority. The computer readable medium also includes program instructions for generating a random secret value corresponding to the credential, as well as program instructions for storing the random secret value in a secret file that can be modified and retrieved only by the first user.

[0009] In yet another embodiment, a computer system configured to limit access by users to networked services on a computer network includes a local security authority configured to authenticate the identity of a user, to determine a credential corresponding to the user, to generate a random secret value corresponding to the determined credential, and to determine authorization information associated with both the user and an application. The computer system also includes a local security authority memory associated with the local security authority, configured only by operation of the local security authority, as well as computer-readable memory configured to store a secret file which is configured to store the random secret value and which is readable substantially only by processes executed by the user.

[0016] A system, method and apparatus for limiting access by a user to a networked application or service is described. In particular, access to network security credentials that allow a user to authenticate to application servers is more effectively controlled. This is accomplished by storing the user's credentials in memory that is only accessible by a local security authority (LSA). A secret associated with each credential is stored in a secret file which is accessible only by the associated user. When this secret is passed to the LSA by the user, the LSA passes back a handle to the appropriate credential, which the user can later use to obtain authentication information through the LSA. Thus, to access a credential, a user must conform with the file system access control to first access the secret, then conform with the LSA access control to obtain the credential handle.

[0017] 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 to one skilled in the art, however, 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.

[0018] FIG. 1 is a schematic of a computer system 200 according to an embodiment of the present invention. A host 202 is connected to a network 204 via a transmission medium 206. The network 204 can include one or more local area networks (LANs) and/or wide area networks (WANs), including the Internet. The network 204 is configured to facilitate communication between the various hardware and software which are connected to it. The transmission medium 206 can include coaxial cables, copper wire, fiber optics, acoustic or light waves, such as those generated during radio-wave and infra-red data communications, and/or any other suitable medium for communicating data.

[0019] The host 202 can be, for example, a user terminal or machine including the components of the computer system 600 of FIG. 5 below. The host 202 includes an operating system (OS) 214 for managing the internal functions of the host 202, and controlling the host operations and file system. As an example, the OS 214 can be a Unix OS, examples of which are OS™ and SolariS™ by Sun Microsystems, Inc. of Palo Alto, Calif.; IRIX™ by Silicon Graphics, Inc. of Mountain View, Calif.; HPUX™ of Hewlett-Packard of Palo Alto, Calif.; or Linux. Included in its functions, the OS 214 controls access to files (not shown) that are resident on the host 202 and interactions by the host 202 with the network 204.

[0020] The host 202 also includes a logon program 208 which can be invoked by one or more users to initiate one or more corresponding logon processes LP-1 through LP-n. The logon processes LP-1 through LP-n operate interactively with the corresponding users to facilitate logon of the user to the host 202. Typically, a single user, here represented by USER-1, directly interacts with the host 202 through a direct interface 209. The direct interface can include a mouse, a keyboard, or any other suitable input device, such as those described below with reference to FIG. 5. In addition to the direct user USER-1, remote users USER-2 through USER-n can remotely log onto the host 202 via remote hosts HOST-2 through HOST-n that are connected to the host 202 via the network 204 and transmission media 206. As is well known in the art, the remote users USER-2 through USER-n can remotely log on via a direct interface 209 to a corresponding remote host HOST-2 through HOST-n, and then via a remote logon mechanism that provides data communication between the host 202 and the remote host HOST-2 through HOST-n. Any suitable remote logon mechanisms can be used, such as those commonly referred to as rlogin, telnet, or ssh. Each such remote logon by remote users USER-2 through USER-n can invoke a corresponding logon process LP-2 through LP-n on the host 202. In this way, multiple users can be logged onto and use the host 202 at substantially the same time.

[0021] The host 202 can also include an application service or client 210 and related security library 212. For example, the application client 210 can be a web browser or a directory browser. The network 204 is connected, via a transmission medium 206, to an application server 216 which is configured to act in response to requests from the application client 210 under certain conditions. Of course, host 202 can also include one or more other application clients (not shown) which can make requests to other application servers (not shown) connected to the network 204.

[0022] A local security authority (LSA) 222 is also included on the host 202. The LSA 222 can be a computer program or software resident on memory of the host 202. In alternative embodiments, the LSA 222 can reside on other memory that is associated with another host connected to the host 202 or that is associated with any other suitable hardware, with such memory being connected to the host 202 either directly or via the network 204. Processes of the LSA 222 can be performed independently from other processes by a processor (refer to FIG. 5 below) of the host 202 or any other suitable processor that is connected to the memory where the LSA 222 resides. Because the LSA operates as a separate process, other processes of the computer system 200 are substantially prohibited from accessing the memory of the LSA.

[0023] Memory associated with the LSA 222 includes one or more credentials CRED-1 through CRED-n which are associated with logged-on users USER-1 through USER-n, respectively. The credentials CRED-1 through CRED-n can be used to obtain authentication information that can be used to authenticate the user of an application client, such as application client 210, to an application server, such as application server 216. Because the credentials reside in the LSA which operates by separate processes, access to the credentials is limited to processes that first interact with the LSA itself.

[0024] The credentials CRED-1 through CRED-n each also correspond to file-based-secrets FBS-1 through FBS-n, respectively, which are located in secret files SF-1 through SF-n, respectively. The secret files SF-1 through SF-n can reside in memory of the host 202 or in memory otherwise connected to the host 202 through the network 204. Read and write access to the secret files SF-1 through SF-n can be limited to the user to which the credential corresponds, i.e., USER-1 through USER-n, respectively. To limit access in this way, the secret files SF-1 through SF-n are subject to a form of user-based access control, for example a file system of a host on which the secret files reside. Also, each secret file can have one or more characteristics which identify it as corresponding to the associated user. For example, the secret file can have a name that has a component that is common to all such secret files, and another component that corresponds to the user's user name, sometimes referred to as the user's userid.

[0025] A security server 226 is connected to the network 204 via transmission media 206. For example, the security server 226 can be utilize any suitable authentication system, such as a Kerberos system which is well known to those skilled in the art. The security server 226 can operate in response to requests by the LSA 222. In particular, and as further described below with respect to the process diagram of FIG. 2, the security server 226 can facilitate the determination of the credentials CRED-1 through CRED-n and the corresponding authentication information for a given application client.

[0026] FIG. 2 is a process diagram of a method 300 for producing a file-based-secret (FBS) as part of a method of limiting access of a user to a networked application. As an example, all or some of the operations of method 300 can be carried out by the LSA 222 of FIG. 1.

[0027] In operation 302, user information is received. This operation can occur substantially at the same time that a user or process logs onto the host 202, and at each such time a user or process logs on. The user information can include, for example, any information that identifies a process, a user, a group of users, or a particular capacity of a user or group of users. As a specific example, the user identification information can include a user name, a domain name, and a password. The user identification information can be entered into the computer system 300 through any suitable user interface, such as keyboard, mouse, etc. as discussed below with reference to FIG. 5. Such entry can also be performed in conjunction with one or more of a logon program, such as the logon program 208 of FIG. 1, and other hardware and/or software, for example smart cards. In particular, the logon program can interactively prompt the user for the user identification information. In a specific example, the logon program then passes the user information via an interprocess communication (IPC) channel to the LSA. In the case of a process logging onto the host 202, another suitable logon mechanism can be used to facilitate entry of the user information of the process attempting to log on and to transfer such information to the LSA.

[0028] The user corresponding to the user information is authenticated in operation 304. For example, it is determined whether the user is authorized to use the account identified by the user name, given the password received in operation. More specifically, the LSA can create a request using the user information of operation 302, and send such request to the security server. The security server can then pass a response to the LSA from which the LSA can determine whether the user is authenticated. This response can then be passed from the LSA to the logon program which can display the response to the user.

[0029] The user credential is determined in operation 306. This credential corresponds to the particular user whose user information was received in operation 302. The credentials can be determined, for example, by the LSA 222 engaging in an exchange, including using the user information, with the security server. More specifically, the exchange can be a Kerberos exchange, or an exchange governed by any other suitable authentication protocol.

[0030] In operation 308, a random secret that is correlated with the credential is generated. This random secret is provided in, or written to, a file that is readable and writeable only by the user to which the credential corresponds, in operation 310. Hence, a file-based-secret (FBS) is formed. As an example, the LSA can generate the random secret and place the random secret in the file. The file, or secret file, can have one or more characteristics which identify it as corresponding to the associated user. For example, the secret file can be created with a name that has a component that is common to all such secret files, and another component that corresponds to some user-specific information, such as the user's numeric uid in a Unix environment.

[0031] A process diagram of a method 400 for using a file-based-secret to limit access to a networked application client or service is shown in FIG. 3. The method 400 includes a security library receiving a request to acquire a credential handle in operation 402 shown in FIG. 3. Such a request can be made by the application client associated with the security library, and initiated in response to a user (“the present user”) invoking the application client or otherwise provoking the application client to attempt a connection to another entity on the network, such as the associated application server. For example, the present user can invoke a web browser on the host to access a web page that is linked to another web page that is currently displayed on the host. Thus, operation 402 can occur each time a user invokes a networked application.

[0032] The request of operation 402 can include one or more aspects of the user information, for example, the user's userid and/or uid. Alternatively, the security library can acquire the user information by calling the system operating system (OS).

[0033] In operation 404, the security library retrieves a secret from the secret file (described in FIG. 2), that corresponds to the present user. This retrieval is accomplished by correlating the user information received by the security library, with characteristics of the file that identify it as corresponding to the present user. For example, the security library can look for a file having a known common component and having another component that matches the userid acquired by the security library in operation 402.

[0034] The secret retrieved in operation 404 is passed to the LSA in operation 406 by the security library. The security library can pass the secret through an interprocess communication (IPC) channel, which can be opened, for example, by the security library before or as part of operation 404. In operation 408 the LSA identifies the credential to which the secret corresponds, according to the formation of the secret by the LSA in operation 308 of FIG. 2. The LSA then passes a credential identifier to the application client, via the security library, in operation 410. This credential identifier can be a handle or any other suitable type of information that the application client, through the security library, can later pass to the LSA and thereby facilitate identification of the appropriate credential by the LSA.

[0035] The security library receives a request from the application client to initialize a security context, in operation 412. This request includes passing the credential identifier, or handle, to the security library. In response to the application client request in operation 412, the security library passes the credential handle to the LSA in operation 414, shown in FIG. 3. In operation 416, the LSA uses the credential handle to identify the credential. Also in operation 416, the LSA uses the credential to obtain authentication information from the security server. For example, the LSA can initiate and conduct an exchange of information with the security server, including passing the credential to the security server and receiving the authentication information from the security server. In the particular example of a Kerberos security server, the LSA can use the credential to obtain a service ticket that includes a key and that corresponds to the present user, the application client requesting the security context, and/or the network service with which the application client is attempting to initialize a security context.

[0036] In operation 418, the LSA passes the authentication information to the security library. For example, in the example where the authentication information is a Kerberos ticket, the LSA can format and send to the security library a Generic Security Service Application Program Interface (GSSAPI) Kerberos initialize security context token (KISCT) containing the service ticket and an authenticator. In addition, the LSA can maintain a copy of the authentication information.

[0037] In operation 420 the security library passes the authentication information received in operation 418, to the application client. In subsequent operations, the application client can use the authentication information passed by the security library in operation 420, to attempt access to the related application server (i.e., authenticate the application client to the application server), and to thereby fulfill the user's invocation of the application client. Such subsequent operations by the application client and application server are well known to those skilled in the art. Operations 412 through 420 can be performed again to reestablish a security context with the same network service, or to establish a security context with a different network service.

[0038] FIG. 4 is a process diagram of a method 500 for limiting access to a networked application, according to an embodiment of the present invention. In operation 502 of method 500, a security library retrieves a secret from a file. The security library may perform operation 502 in response to a request from an application client that has been invoked by a present user. Such a request can be either directly or indirectly associated with initializing a security context for the application client. The file, or secret file, from which the secret is retrieved in operation 502 corresponds to and is readable and writeable by only the present user.

[0039] Operation 504 includes the security library passing the secret to an LSA. The LSA uses the secret passed in operation 504 to identify, in operation 506, a credential located in memory associated with the LSA processes. The LSA identifies the credential based on a predefined one-to-one correspondence with the secret.

[0040] In operation 508, the LSA uses the credential to obtain authentication information from a security server. Operation 508 can be similar and include the same or similar aspects as operation 416 of method 400 in FIG. 3. Also, the authentication information can be any suitable information that characterizes the authority the user has to invoke the application, such as a Kerberos ticket. The LSA then passes the authentication information to an application client that is associated with the security library of operation 502. In addition, the LSA can retain a copy of the authentication information in memory associated with the LSA processes. As discussed above with reference to FIG. 3, the application client can then use the authentication information to attempt connections within the network 200.

[0041] In this disclosure, including in the claims, certain process steps are set forth in a particular order, and alphabetic and alphanumeric labels are used to identify certain steps. Unless specifically stated in the disclosure, embodiments of the invention are not limited to any particular order of carrying out such steps. In particular, the labels are used merely for convenient identification of steps, and are not intended to imply, specify or require a particular order of carrying out such steps.

[0042] With the various embodiments, access to networked applications or services can be more tightly controlled. More particularly, access to the credentials of the various users can be more controlled with inclusion of the LSA as described herein. While access to the file-based-secrets can be controlled by the file system of the host wherein the secret files reside, further access control is imposed by maintaining the credentials in the memory associated with the LSA processes. Because the application client never has direct access to the credential it cannot evade the LSA access control. Also, the application cannot send the credential off the host to be used later, and thereby evade the file system controls as well. In addition, because the user, through operation of the security library, must go through the LSA to acquire the credential, the LSA can again authenticate the user. Thus, this invention allows the LSA to implement a hardware-based security perimeter on a computer system implementing an operating system (OS) that enforces process isolation (i.e., one process cannot access the memory associated with another process), for example a Unix OS. All user access to credentials can be audited and checked at the time such access is requested, since every such access request must pass through the LSA. Thereby, the user-level access control to networked application clients and services is increased by the LSA and file-based-secret system aspects of the current invention.

[0043] Additionally, the LSA can be configured to further scrutinize the user's request via the security library for the credential and thereafter the authentication information. For example, the LSA can be configured to evaluate additional characteristics of the user's request, such as the application client from which the request is being made. In such a case, the LSA could be used to provide access control to application clients on a per process basis, thereby providing a more fine-grained access control.

[0044] In an example of such an embodiment on a computer system implementing a UNIX operating system, the setuid mechanism is used. The goal is, when a trusted application, App-T, is invoked, to give it a full set of network privileges, e.g., group memberships, that are associated with the invoking user, for example User-1. When the LSA is invoked, it will create an FBS that is readable only by the account which owns the App-T executable. When a lesser-trusted application, App-G, is invoked by User-1, a subset of User-1's network privileges are given to the application App-G. In other words, a trusted application App-T will operate with a superset of User-1's group memberships, relative to the lesser-trusted applications. When User-1 logs on to the computer system, two sets of credentials are created. In addition, an FBS corresponding to the user (i.e., readable only by the user) is created, as in the previous discussion regarding per-user access control. The first credential includes all of User-1's group memberships, while the second credential has a subset of the group memberships. An exchange between the LSA and the security server, in addition to that described above, can be used to obtain the second credential associated with User-1. This scheme can be extended to multiple credentials corresponding to multiple applications, each with different access rights.

[0045] The workstation obtains the information regarding which credentials (and, e.g., with which group memberships) to obtain by consulting local policy. In the above case, the more powerful first credential (i.e., the credential which provides the greater amount of access) is associated with the FBS which is readable by the App-T account which owns the executable file of the trusted application App-T. When the security library attempts to acquire the handle of the appropriate credential, the LSA uses the ps command to determine whether the trusted application App-T is making the call. If so, the security library uses the setuid call to obtain and send to the LSA, the App-T FBS and the FBS corresponding to the user. The LSA then checks each of the trusted application's ancestor processes (using the ps command), for each copy of the trusted application, to ensure that these ancestor processes are not potentially malicious processes:

• • [0046] for each process with executable file equal to the trusted application executable file {
    • [0047] for each ancestor process starting with the immediate parent {
      • [0048] if ancestor process not trusted return bad status to security library for AcquireCredentialsHandle
      • [0049] (list of trusted ancestor process executable files is obtained by consulting local policy)
    • [0050] }
  • [0051] }

[0052] The LSA then returns a credential handle associated with the App-T credential. Of course there can be more than one identified trusted application and the lesser-trusted applications can have one of one or more subsets of the user's rights.

[0053] Such a security system can limit access to the application clients more precisely, thereby giving users the maximum authorized access while maintaining a higher degree of security. This improved limit of access to application clients therefore also results in improved limit of access to any other aspects of the computer system with which the application may interact. For example, if the application has the capability to affect a directory within the computer system, improving access control to the application can result in improved access control to the directory.

[0054] While the above-described methods can be used with a single user, they can also be used with multiple users of the same computer system, and with multiple applications. In cases involving multiple users, the method 300 of FIG. 2 is performed for each user or process. Thus, there will be a separate credential for each user, with the credential corresponding to a separate secret in a separate file. The security library can access the particular file and obtain the particular resident secret that corresponds to the user that is attempting to access an application. The LSA can then determine the particular credential that corresponds to that particular secret, and eventually pass on the authentication information corresponding to the user and the particular invoked application client. Of course, the methods of FIG. 2 and FIG. 3 can be used in a computer system including one or more networked applications, while one or more of which are invoked by one or more users. Thus, these methods can facilitate enhancing security of the computer system with networked application clients and multiple users.

[0055] FIG. 5 is a block diagram that illustrates a computer system 600 upon which an embodiment of the invention may be implemented. Computer system 600 includes a bus 602 or other communication mechanism for communicating information, and a processor 604 coupled with bus 602 for processing information. Computer system 600 also includes a main memory 606, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 602 for storing information and instructions to be executed by processor 604. Main memory 606 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 604. Computer system 600 further includes a read only memory (ROM) 608 or other static storage device coupled to bus 602 for storing static information and instructions for processor 604. A storage device 610, such as a magnetic disk or optical disk, is provided and coupled to bus 602 for storing information and instructions.

[0056] Computer system 600 may be coupled via bus 602 to a display 612, such as a cathode ray tube (CRT), for displaying information to a computer user. An input device 614, including alphanumeric and other keys, is coupled to bus 602 for communicating information and command selections to processor 604. Another type of user input device is cursor control 616, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 104 and for controlling cursor movement on display 112. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane.

[0057] The invention is related to the use of computer system 100 for limiting user access to networked applications. According to one embodiment of the invention, application access security is provided by computer system 100 in response to processor 104 executing one or more sequences of one or more instructions contained in main memory 106. Such instructions may be read into main memory 106 from another computer-readable medium, such as storage device 110. Execution of the sequences of instructions contained in main memory 106 can cause processor 104 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.

[0058] The term “computer-readable medium” as used herein refers to any medium that can participate in providing instructions to processor 104 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, optical or magnetic disks, such as storage device 110. Volatile media include dynamic memory, such as main memory 106. Transmission media include coaxial cables, copper wire and fiber optics, including the wires that comprise bus 102. Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications.

[0059] Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium; a CD-ROM, any other optical medium; punchcards, papertape, any other physical medium with patterns of holes; a RAM, a PROM, an EPROM, a FLASH-EPROM, any other memory chip or cartridge; a carrier wave as described hereinafter; or any other medium from which a computer can read.

[0060] Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to processor 104 for execution. For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system 100 can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red detector can receive the data carried in the infra-red signal and appropriate circuitry can place the data on bus 102. Bus 102 carries the data to main memory 106, from which processor 104 retrieves and executes the instructions. The instructions received by main memory 106 may optionally be stored on storage device 110 either before or after execution by processor 104.

[0061] Computer system 100 also includes a communication interface 118 coupled to bus 102. Communication interface 118 provides a two-way data communication coupling to a network link 120 that is connected to a local network 122. For example, communication interface 118 may be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface 118 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface 118 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

[0062] Network link 120 typically provides data communication through one or more networks to other data devices. For example, network link 120 may provide a connection through local network 122 to a host computer 124 or to data equipment operated by an Internet Service Provider (ISP) 126. ISP 126 in turn provides data communication services through the world wide packet data communication network now commonly referred to as the “Internet” 128. Local network 122 and Internet 128 both use electrical, electromagnetic and/or optical signals that carry digital data streams. The signals through the various networks and the signals on network link 120 and through communication interface 118, which carry the digital data to and from computer system 100, are exemplary forms of carrier waves transporting the information.

[0063] Computer system 100 can send messages and receive data, including program code, through the network(s), network link 120 and communication interface 118. In the Internet example, a server 130 might transmit a requested code for an application program through Internet 128, ISP 126, local network 122 and communication interface 118. In accordance with the invention, one such downloaded application provides for networked application security as described herein.

[0064] Processor 104 may execute the received code as it is received, and/or the received code can be stored in storage device 110 or other non-volatile storage for later execution. In this manner, computer system 100 may obtain application code in the form of a carrier wave.

[0065] In summary, the present invention provides methods and apparatuses for limiting access by users to networked services on a computer system, whereby greater security and access control can be realized while minimizing the computer system complexity. The present invention can be particularly useful where the user attempts access to a networked service through a host having a Unix-based operating system. Alternatively, the present invention can be implemented on host systems with a different operating system that prevents processes from accessing the memory of the operating system and the memory of other processes. The invention has been described herein in terms of several specific embodiments. Other embodiments of the invention, including alternatives, modifications, permutations and equivalents of the embodiments described herein, will be apparent to those skilled in the art from consideration of the specification, study of the drawings, and practice of the invention. For example, while the Local Security Authority (LSA), application client, and other elements of the computer system of the present invention have been described as located on a single host, alternatively these elements can be on one or more different hosts. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. The embodiments and specific features described above should be considered exemplary, with the invention being defined by the appended claims, which therefore include all such alternatives, modifications, permutations and equivalents as fall within the true spirit and scope of the present invention.