as United States
`a2) Patent Application Publication co) Pub. No.: US 2004/0034623 Al
`(43) Pub. Date: Feb. 19, 2004
`
`Salmen
`
`US 20040034623A1
`
`(54) METHOD AND APPARATUS FOR
`RESTRICTED RUN-TIME ENVIRONMENT
`WITH DYNAMIC USER CONTEXT
`
`(75)
`
`Inventor: Helmut Salmen, Los Gatos, CA (US)
`
`Correspondence Address:
`Brian M.Berliner
`O’MELVENY & MYERS LLP
`400 South HopeStreet
`Los Angeles, CA 90071-2899 (US)
`
`(73) Assignee: SUN MICROSYSTEMS, INC.
`
`(21) Appl. No.:
`
`10/223,779
`
`(22)
`
`Filed:
`
`Aug. 19, 2002
`
`Publication Classification
`
`(ST) Ute C07 aicesccscssessscsessssssnssnstnsessevee GO6F 17/30
`
`(52) US. Che
`
`cescssessssnssssinstnstntsesnesstsesstsstsnssenee 707/2
`
`ABSTRACT
`(57)
`Embodiments of the present invention are directed to a
`method and apparatus for restricted run-time environment
`with dynamic user context. In one embodiment, a user
`interacts with the computer system through a restricted
`run-time environment. When the user begins using the
`computer system at a local machine (i-e., a client), a user
`context is dynamically created at the local machine. Then, a
`userinterface is initiated in the run-time environment which
`is isolated from the local machine’s system files. In one
`embodiment, the user interface andall actions resulting from
`interaction through the interface take place in the isolated
`run-time environment.
`In one embodiment,
`the isolated
`run-time environment contains its own sct of system files
`that the user may need to access. In one embodiment, the
`local machine is running the Unix™ operating system. A
`user interacts with the system through an interface running
`from the chroot directory.
`
`
`
`100
`Client Tier
`
`110
`Client (e.g.,
`Browser)
`
`140
`130
`Application Tier
`DatabaseTier
`
`120
`Application
`Server
`
`150Database
`Server
`
`Google Exhibit 1072
`Google v. VirtaMove
`
`Google Exhibit 1072
`Google v. VirtaMove
`
`

`

`Patent Application Publication
`
`Feb. 19, 2004 Sheet 1 of 15
`
`US 2004/0034623 Al
`
`
`
`130
`140
`Database Tier
`Application Tier
`
`100
`Client Tier
`
`110
`Client (e.g.,
`Browser)
`
`150
`Database
`Server
`
`120
`Application
`Server
`
`Figure 1
`
`

`

`Patent Application Publication
`
`Feb. 19,2004 Sheet 2 of 15
`
`US 2004/0034623 Al
`
`
`
`210
`
`200
`
`220
`
`
`
`Figure 2
`
`

`

`Patent Application Publication
`
`Feb. 19, 2004 Sheet 3 of 15
`
`US 2004/0034623 Al
`
`
`
`300
`
`
`User Requests
`Access to
`
`Computer System
`at Local Machine
`
` 310
`
`Restricted Run-
`Time Environment
`Made Available to
`User
`
`
`
`
`
` 320
`
`User Context
`
`
`
`
`Dynamically
`Created at Local
`Machine for User
`
`
`
` 330
`
`User Interface
`
`
`Initiated in
`
`
`
`
`Restricted Run-
`Time Environment
`
`
`Figure 3
`
`

`

`Patent Application Publication
`
`Feb. 19,2004 Sheet 4 of 15
`
`US 2004/0034623 Al
`
`400
`
`410
`
`420
`
`430
`
`Figure 4
`
`

`

`Patent Application Publication
`
`Feb. 19, 2004 Sheet 5 of 15
`
`US 2004/0034623 Al
`
`
`500
`User Requests
`Access to
`Computer System
`at Local Machine
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` 510
`
`Restricted Run-
`Time Environment
`That ContainsIts
`Own Set of
`System Files for
`Use by User Made
`Available to User
`
` 520
`
`User Context
`
`
`Dynamically
`
`
`Created at Local
`Machine for User
`
`
`
` 530
`
`User Interface
`
`
`Initiated in
`Restricted Run-
`
`
`Time Environment
`
`
`
`
`Figure 5
`
`

`

`Patent Application Publication
`
`Feb. 19, 2004 Sheet 6 of 15
`
`US 2004/0034623 Al
`
`
`
`
`
`600
`User Requests
`
`Access to
`Computer System
`at Local Machine
`
`
`
`
`
`
`
`
` 620
`
`User Context
`
`
`Dynamically
`
`
`Created at Local
`Machine for User
`
` 610
`
`Chroot
`
`Environment Made
`Available to User
`
` 630
`
`
`
`User Interface
`Initiated in Chroot
`Environment
`
`
`
`
`Figure 6
`
`

`

`Patent Application Publication
`
`Feb. 19,2004 Sheet 7 of 15
`
`US 2004/0034623 Al
`
`
`
`
`
`700
`Level 1
`
`
`
`
`
`Figure 7
`
`

`

`Patent Application Publication
`
`Feb. 19,2004 Sheet 8 of 15
`
`US 2004/0034623 Al
`
`Context for User
`
`810
`Local User
`Contextis
`Dynamically
`Generated for
`User
`
`800
`User Requests to
`Connectto
`Computer System
`
`820
`User Interface
`Initiated Using
`Local User
`
`Figure 8
`
`

`

`Patent Application Publication
`
`Feb. 19,2004 Sheet 9 of 15
`
`US 2004/0034623 Al
`
`900
`User Requests to
`Connect to
`Computer System
`
`910
`Is User Context
`Data on System
`Available?
`
`Yes
`
`No
`
`
`
`
`920
`User Context Data
`
`
`Downloaded From
`
`
`System
`
`
` 930
`User Context Data
`
`
`From System
`
`
`Combined With
`
`
`Default User
`
`
`Context Data
`
`
`Stored at Local
`
`
`Machine to
`Generate Local
`
`
`User Context
`
`User Context
`
`940
`Default User
`Context Data
`Stored at Local
`Machine Used to
`Generate Local
`
`
`
`950
`User Interface
`Initiated Using
`Local User
`Context for User
`
`Figure 9
`
`

`

`Patent Application Publication
`
`Feb. 19, 2004 Sheet 10 of 15
`
`US 2004/0034623 Al
`
`
`
`1000
`User Context Data
`
`
`Downloaded From
`
`System
`
`
`
`
`
`
` 1010
`Local User
`
`
`Context
`
`
`Generated Using
`Downloaded User
`
`Context Data
`
` 1020
`
`User Interface
`
`
`Initiated Using
`
`
`Local User
`Context
`
`
`
` 1030
`
`User Alters Part of
`
`
`User Context Data
`
`
`That Is Stored on
`System
`
`
` 1040
`
`
`User Logs Out
`
`
`And Altered User
`Context Data Is
`
`
`Uploaded to
`
`
`System for
`Persistent Storage
`Figure 10
`
`

`

`Patent Application Publication
`
`Feb. 19,2004 Sheet 11 of 15
`
`US 2004/0034623 Al
`
`Start
`
`a
`
`1100
`Local User
`Context
`Dynamically
`Generated
`
`
`
`1160
`Aspectof Local
`
`
`User Context
`
`Altered And
`
`Marked for
`Persistent
`
`Alteration
`
`
`
`
`
`
`
`1180
`1170
`User Logs Off And All
`
`
`Persistent Alterations of
`Does User
`
`Local User Context Are
`Attempt More
`
`Alterations?
`Uploaded to System for
`Persistent Storage
`
`
`
`
`
`
`
`
`
`Figure 11
`
`1110
`User Attempts to
`Alter Aspect of
`Local User
`Context
`
`
`1120
`Is User Allowed to
`
`Alter the Aspect of
`ocal User Context?
`
`1130
`
`
`| Permission to Alter |-—- -—
`the Aspect Denied
`
`
`
` 1150
`1140
`Is User Allowed to
`
`Aspect of Local
`
`
`User Context
`Persistently Alter the
`
`
`Temporarily
`Aspect of Local User
`
`
`
`Altered
`Context?
`
`
`
`

`

`Patent Application Publication
`
`Feb. 19,2004 Sheet 12 of 15
`
`US 2004/0034623 Al
`
`Centra! ServerInstallation
`1200
`
`1210
`
`End User Hardware
`
`Figure 12
`
`

`

`Patent Application Publication
`
`US 2004/0034623 Al
`
`Feb. 19, 2004 Sheet 13 of 15
`
`1300
`
`Figure 13
`
`

`

`Patent Application Publication
`
`Feb. 19, 2004 Sheet 14 of 15
`
`US 2004/0034623 Al
`
`1410
`
`Video
`
`Decoder
`1409
`
`Video
`Controller
`
`
`
`
`
`
`
`
`Vai}
`Video
`Encoder
`
`[4
`
`
`
`1408
`Smartcard
`Interface
`
`1412
`PCI Bus
`
`1415
`a
`
`
`
` 1401
`
`
`
`
`
`1 40.1
`Embedded
`Processor
`
`
`
`
`
`1406
`DRAM
`
`
`
`
`1403
`1402
`Audio H——_ Network
`Codec
`Contro! Block
`
`
`
`USB
`Controller
`
`
`
`
`
`
`
`
`
`
`
`1414
`
`1413
`
`<a
`1416
`
`Figure 14
`
`

`

`Patent Application Publication
`
`Feb. 19,2004 Sheet 15 of 15
`
`US 2004/0034623 Al
`
`
`
`
`1507
`Memory
`
`1506
`Video Controller/Interface
`
`oe;
`Controller
`
`
`
`Figure 15
`
`
`
`1504
`Interconnect
`Interface
`
`4501
`CPU
`
`
`
`1505
`4502
`Internal Bus
`Graphics
`
`Controller
`Renderer
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`

`

`US 2004/0034623 Al
`
`Feb. 19, 2004
`
`METHOD AND APPARATUS FOR RESTRICTED
`RUN-TIME ENVIRONMENT WITH DYNAMIC
`USER CONTEXT
`
`BACKGROUND OF THE INVENTION
`
`[0001]
`
`1. Field of the Invention
`
`[0002] The present invention relates to the field of com-
`puter user interfaces and,
`in particular,
`to a method and
`apparatus for restricted rin-time environment with dynamic
`user context.
`
`Sun, Sun Microsystems, the Sun logo, Solaris and
`[0003]
`all Java-based trademarks and logos are trademarks or
`registered trademarks of Sun Microsystems, Inc.,
`in the
`United States and other countries. All SPARC trademarks
`are used under license and are trademarks of SPARCInter-
`national, Inc.,
`in the United States and other countries.
`Products bearing SPARC trademarks are based upon an
`architecture developed by Sun Microsystems, Inc.
`
`[0004]
`
`2. Background Art
`
`In some computer systems(e.g., thin client archi-
`[0005]
`tectures) much of a uscr’s data and computation is main-
`tained and performed at a remote location using a server
`computer. Whenall of the data or computation necessaryfor
`a user’s task is handled by a server, the user may easily
`interact with the system at different locations using different
`client computing devices. However,
`some applications
`require or prefer some data or computation to be handled at
`the client computer. Using prior art methods, the client’s
`system data is vulnerable to tampering by a malicious user.
`Before further discussing the drawbacksof current schemes,
`it is instructive to discuss a computer architecture wherethis
`problem occurs.
`
`[0006] Multi-Tier Application Architecture
`
`In the multi-tier application architecture, a client
`[0007]
`communicates, for example, requests to a server for data,
`software and services, and the server
`responds to the
`requests. The server’s response may entail communication
`with a database management system for the storage and
`retrieval of data.
`
`[0008] The multi-tier architecture includes at least a data-
`base tier that includes a database server; an application tier
`that includes an application server and application logic(i.e.,
`software application programs, functions,etc.); and a client
`tier. ‘the data base server responds to application requests
`received from the client. The application server forwards
`data requests to the database server.
`
`[0009] FIG. 1 provides an overview of a multi-tier archi-
`tecture. Client tier 100 typically consists of a computer
`system that provides graphic user interface (GUI) generated
`by a client 110, such as a browser or other user interface
`application. Conventional
`browsers
`include
`Internet
`Explorer and Netscape Navigator, among others. Client 110
`gencratcs a display from, for cxample, a specification of
`GUIelements (e.g., a file containing input, form, and text
`elements defined using the Hypertext Markup Language
`(HTML)) and/or from an applet (i.c., a program written in
`the Java™ programming language or another platform inde-
`pendent programming language which runs when it
`is
`loaded bythe browscr).
`
`{0010] Further application functionality is provided by
`application logic managed by an application server 120 in
`applicationtier 130. The apportionmentof application func-
`tionality between client tier 100 and application tier 130 is
`dependent upon whether a “thin client” or a “thick client”
`topology is desired. In a thin client topology, the clienttier
`(i.e., the end user’s computer) is used primarily to display
`output and obtain input while the computing takes place in
`otherticrs. On the other hand, a thick clicnt topology uscs a
`more conventional, general purpose computer which has
`processing, memory,and data storage abilities. Database tier
`140 contains the data that is acecssed by the application
`logic in application tier 130. Database server 150 manages
`the data and/orits structure, as well as the operations that can
`be performed on the data and/or its structure.
`
`[0011] Application server 120 can include applications
`such as a corporation’s scheduling, accounting, personnel
`and payroll applications. Application server 120 manages
`requests for the applications that are stored therein. Appli-
`cation server 120 can also manage the storage and dissemi-
`nation of production versions of application logic. Database
`server 150 manages the database(s) thal manage data for
`applications. For example, database server 150 responds to
`requests to access the scheduling, accounting, personnel and
`payroll applications’ data.
`
`[0012] Connection 160 is used to transmit data between
`client tier 100 and applicationtier 130, and mayalso be used
`to transfer the application logic to client tier 100. The client
`tier can communicate with the application tier via, for
`example, a Remote Method Invocator (RMI) application
`programming interface (API) available from Sun Microsys-
`tems™. The RMT API provides the ability to invoke meth-
`ods, or software modules, that reside on another computer
`system. Parameters are packaged and unpackagedfortrans-
`mittal to and from the client tier. Connection 170 between
`
`application server 120 and database server 150 represents
`the transmission of requests for data and the responses to
`such requests from applications that reside in application
`server 120.
`
`[0013] Elements of the client tier, the application tier and
`the databasetier (¢.g., client 110, application server 120 and
`database server 150) may execute within a single computer.
`However,in a typical system, elements of the clienttier, the
`application tier and the database tier may execute within
`separate computers interconnected over a network such as a
`LAN (cal area network) or WAN (wide area network).
`
`[0014] Local Machine System Security
`
`If all of the user’s data and computation (task) is
`[0015]
`handled at the remote location, the user will not need to
`create any files or modify anyexisting files on the client.
`Thus, in such a system, the user often is prevented from
`creating or modifying localfiles, which prevents a malicious
`user from damaging the local machine’s system information,
`yet, still enables full use of the system. However, if some
`uscr task requires that the uscr be able to ercate or modify
`a local file, in prior art methods, a malicious user may be
`able to modify and damage the local machine’s system
`information (i.c., the system information in the clicnt ticr).
`Thus, a need exists to allowa userto create or modify a local
`file while preventing a malicious user from modifying or
`damaging the local machine’s system information.
`
`

`

`US 2004/0034623 Al
`
`Feb. 19, 2004
`
`SUMMARY OF THE INVENTION
`
`[0016] Embodiments of the present invention are directed
`to a method and apparatus for restricted run-time environ-
`ment with dynamic user context. In one embodimentof the
`present invention, a user interacts with the computer system
`through a restricted run-time environment. When the user
`begins using the computer system al a local machine (ie., a
`client), a user context is dynamically created at the local
`machine. Then, a user interface is initiated in the run-time
`environment which is isolated from the local machine’s
`system files.
`
`the user interface and all
`In one embodiment,
`[0017]
`actions resulting therefrom occurs in the isolated run-time
`environment.
`In one embodiment,
`the isolated run-time
`environment contains its own set of system files available
`for user access.
`
`In one embodiment, the local machine is running
`[0018]
`the Unix™ operating system. A user interacts with the
`system through an interface running from the chroot direc-
`tory. All actions initiated by the interface also run from a
`chroot directory. Thus, a malicious user is unable to tamper
`with the local machine’s system files.
`
`In one embodiment, the user interface requires a
`[0019]
`local user context. Before the user interface is initiated, the
`local user context is dynamically generated for the user. In
`one embodiment, some of the user context data is down-
`loaded from the system to the local machine and incorpo-
`rated in the local user context. In another embodiment, the
`local machine contains default user context data. The default
`user context data is incorporated in the local user context. In
`one embodiment,if the system is unavailable, a default local
`user context is generated from the default user context data.
`
`In one embodiment, the user may persistently alter
`[0020]
`a portion of the user context data from the system. After the
`context data is altered, the altered data is uploaded to the
`system. In another embodiment, the user may temporarily
`alter a portion of the default user context data on the local
`machine. When the user stops using the system (e.g., logs
`out), the temporary alterations are lost and the default user
`context data is restored. In another embodiment, the user is
`prevented from altering some portions of the user context.
`
`In onc cmbodiment, the user interface is a web
`[0021]
`browser (e.g., Netscape). The user displays standard web
`content using the web browser. In one embodiment, the user
`uses applets to adapt to changing needs. In one embodiment,
`the web browser initiates helper applications to perform
`specific tasks (e.g., scripting, Java virtual machine, image
`output, video output or audio output).
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`[0022] These and otherfeatures, aspects and advantages of
`the present invention will become better understood with
`regard to the following description, appended claims and
`accompanying drawings where:
`
`[0023] FIG. 1 is a block diagram of a multi-tier architec-
`ture.
`
`[0024] FIG. 2 is a block diagram of the computing envi-
`ronmentof a local machine in accordance with one embodi-
`
`ment of the present invention.
`
`[0025] FIG. 3 is a flow diagram of the process of user
`interaction with a computer system in accordance with one
`embodimentof the present invention.
`
`FIG.4 is a block diagram of the computing envi-
`[0026]
`ronment of a local machine with a restricted run-time
`environment containing system files in accordance with one
`embodimentof the present invention.
`
`[0027] FIG. 5 is a flow diagram of the process of user
`interaction with a computer system wherein a restricted
`run-time environment contains its own set of system files in
`accordance with onc embodimentof the present invention.
`
`[0028] FIG. 6 is a flow diagram of the process of user
`interaction with a computer system through a local machine
`running a Unix operating system in accordance with one
`embodiment of the present invention.
`
`FIG.7 is a block diagram of a three level protec-
`[0029]
`tion scheme for a local machine in accordance with one
`
`embodiment of the present invention.
`
`FIG.8 is a flow diagram ofthe processof initiating
`[0030]
`a user interface in accordance with one embodiment of the
`present invention.
`
`[0031] FIG. 9 is a flow diagram of the process of gener-
`ating a local user context and initiating a user interface in
`accordance with one embodiment of the present invention.
`
`[0032] FIG. 10 is a flow diagram of the process of
`persistently altering user context data in accordance with
`one embodimentof the present invention.
`
`FIG.11 is a flow diagram of the processofaltering
`[0033]
`a user context in accordance with one embodiment of the
`present invention.
`
`FIG.12 is a block diagram of an example of a thin
`[0034]
`client topology called a virtual desktop system architecture
`in accordance with one embodiment of the present inven-
`tion.
`
`[0035] FIG. 13 is a block diagram of a system wherein
`one or more services communicate with one or more Human
`Input Devices (HIDs) through a communication link, such
`as a network in accordance with one embodimentof the
`present invention.
`
`[0036] FIG. 14 is a block diagram of an example embodi-
`ment of the HID in accordance with one embodimentof the
`
`present invention.
`
`[0037] FIG. 15 is a block diagram of a single chip
`implementation of an HID in accordance with one embodi-
`ment of the present invention.
`
`DETAILED DESCRIPTION OF THE
`INVENTION
`
`[0038] The invention is a method and apparatus for
`restricted run-time environment with dynamic user context.
`In the following description, numcrous specific details are
`set forth to provide a more thorough description of embodi-
`ments ofthe invention.It is apparent, however,to one skilled
`in the art, that the invention may be practiced without these
`specific details. In other instances, well known features have
`not been described in detail so as not
`to obscure the
`invention.
`
`

`

`US 2004/0034623 Al
`
`Feb. 19, 2004
`
`[0039] Restricted Run-Time Environment
`
`In one embodimentofthe present invention, a user
`[0040]
`interacts with the computer system (e.g., a system having a
`multi-tier application architecture) througha restricted run-
`time environment. Whenthe user begins using the computer
`system at a local machine (i-e., a client and/or a simple local
`server, such as a Sunray server that only executes a browser
`for a thin client and/or a plurality of thin clients), a user
`context is dynamically created at the local machine. Then,
`the user interface is initiated in a run-time environment,
`which is isolated trom the local machine’s system files.
`
`In one embodiment, the user context for the user
`[0041]
`can be dynamically created from a preset pool of available
`user contexts. Every time the user initiates the use of the
`system, an available user contextis selected for that user and
`every time that user has completed the use of the system, the
`user context is put back into the pool to be later reused by
`that user and/or another user. The user context may include
`preference information, such as font settings, and/or protec-
`tion information, such as where a user can create files, what
`files a user can access, and/or where the user can access the
`files.
`
`FIG. 2 illustrates the computing environmentof a
`[0042]
`local machine in accordance with one embodiment of the
`present invention. The computing environment 200 of the
`local machine contains system files 210 and a restricted
`run-time environment 220 whichis isolated from the system
`files.
`
`[0043] FIG. 3 illustrates the process of user interaction
`with a computer system in accordance with one embodiment
`of the present invention. At block 300, a user requests access
`to the computer system at a local machine. At block 310, a
`restricted run-time environment is made available to the
`user. Processes(€.g.,
`executing a first program on behalf of
`the user) initiated in the restricted run-time environment and
`all processes spawned by processesinitiated in the restricted
`run-time environment (e.g., executing one or more other
`programson behalf ofthe first program) do not have access
`to anything outside the restricted run-time environment.
`
`[0044] At block 320, a user context is dynamically created
`at
`the local machine for the user. At block 330, a user
`interface (e.g., a browser) is initiated in the restricted run-
`time environment. Since the user interface is initiated in the
`restricted run-time environment, the user will not be able to
`tamper with the local machine’s system files, which are
`maintained outside the restricted run-time environment.
`
`the user interface and all
`In one embodiment,
`[0045]
`actions resulting from interaction through the interface take
`place in the isolated run-time environment. In one embodi-
`ment, the restricted (or isolated) run-time environment con-
`tains its own set of systemfiles the user may need to access.
`Thus, system files in the restricted run-time environment
`may be upgraded for the user without altering a stable set of
`systemfiles used by the local machine.
`
`ment 420. The restricted run-time environment containsits
`ownset of system files 430 that a user mayneed to access.
`
`[0047] FIG. 5 illustrates the process of user interaction
`with a computer system wherein a restricted run-time envi-
`ronment contains its own set of system files in accordance
`with one embodimentof the present invention. At block 500,
`a user requests access to the computer system at a local
`machine. At block 510, a restricted run-time environment
`that contains its own set of system files for use by the user
`is made available to the user. Processes initiated in the
`
`restricted run-time environment and all processes spawned
`by processesinitiated in the restricted run-time environment
`do not have access to anything outside the restricted run-
`time environment.
`
`[0048] At block 520,a user context is dynamically created
`at the local machine(1.e., the client tire) for the user. At block
`530, a user interface is initiated in the restricted run-time
`environment. Since the user interface is initiated in the
`restricted run-time environment, the user will not be able to
`tamper with the local machine’s system files, which are
`maintained outside the restricted run-time environment. The
`system files containedin the restricted run-time environment
`are still at potential risk of user tampering.
`
`[0049] Chroot Environment
`
`In one embodiment, the local machine is running
`[0050]
`the Unix™ operating system. A uscr interacts with the
`system through an interface running from a chroot (or
`change root) directory. All actionsinitiated by the interface
`also run from the chroot directory. The chroot directory (or
`environment) is an alternate root directory that appears as
`the root directory for a given process or set of processes.
`Thus, a malicious user is unable to tamper with the local
`machine’s system files in the main directory because the
`user is confined to the directory tree below the chroot
`directory(i.e., the user only has accessto files stored in the
`directory tree below the chroot directory).
`
`FIG.6 illustrates the process of user interaction
`{0051]
`with a computer system through a local machine running a
`Unix operating system in accordance with one embodiment
`of the present invention. At block 600, a user requests access
`to the computer system at the local machine. At block 610,
`the chroot environment(or directory) is made available to
`the user. The chroot environmentis a restricted run-time
`
`environment; processes initiated in the chroot environment
`and all processes spawned thereby do not have access to
`anything outside the chroot environment.
`
`[0052] At block 620, a user context is dynamically created
`at
`the local machine for the user. At block 630, a user
`interface is initiated in the chroot environment. Since the
`userinterface is initiated in the chroot environment, the user
`will not be able to tamper with the local machine’s system
`files, which are maintained outside the chroot environment.
`However, the system files contained in the chroot environ-
`ment are used by the user and remain at risk for user
`tampering.
`
`FIG.4 illustrates the computing environmentof a
`[0046]
`local machine with a restricted run-time environment con-
`
`taining system files in accordance with one embodiment of
`the present invention. The computing environment 400 of
`the local machine contains system files 410 which are
`maintaincd in isolation from a restricted run-time environ-
`
`In one embodiment, all users of a local machine
`[0053]
`share a single chroot environment. Protection within the
`chroot environmentis provided (only) by the standard Unix
`user semantics. Use of the chroot environment provides
`greater protection for the system resources outside of the
`chroot environment.
`
`

`

`US 2004/0034623 Al
`
`Feb. 19, 2004
`
`[0054] FIG. 7 illustrates a three-level protection scheme
`for a local machine in accordance with one embodiment of
`the present invention. At level one 700, execution is done
`with root permission. A script for initiating a user session
`(e.g., bbrootsession) is run with level one permission to
`create or assign a new Unix user ID, userX (e.g., user0), and
`to set up everything this user needs to run in the chroot
`environment.
`
`[0055] Asecondscript for putting the user in the level two
`710 (e.g., bbcontrol) is then executed (with the new user
`permissions set up in level one 700). At this level 710,
`execution is done in the root file system with the newly
`created or assigned userX permission(e.g., user0 permission
`or user-specific permission) rather than the root permission.
`In addition, scripts for supporting and/or monitoring (e.g.,
`bbstartd) are started, and a script for stating the browser
`(c.g., bbstartbrowscr) is started as a background process.
`The supporting and/or monitoring scripts should reside
`outside the chroot environment but should perform the
`supporting and/or monitoring tasks for the chroot environ-
`ment. The window manager (wm)is also initiated at this
`permission level 710 and does not terminate until the user
`(e.g., user0) logs out of the webtop.
`three
`[0056] The execution then switches to the level
`protection scheme. Level three 720 is the level for user
`applications. ‘The window manager (wm), the browser, and
`any application(s) (defined and/or available in the chroot
`environment) that the window manager and/or the browser
`spawn(orstart) run with level three permission (e.g., a user
`application-specific permission) in the chroot environment.
`Thus,
`the user applications use the system files provided
`within the chroot environment without access to the root
`system files in the environment used by the local machine.
`[0057]
`In addition to increased security,
`the reason for
`using the three-level schemeis to provide for easy cleaning
`or evicting of user-related information when a user exits
`from the system. For example, on exit of a session the
`system only has to scan the process table for processes
`associated with user ids, userX (e.g., user0), and evict them.
`[0058] The cleaning/evicting of user-related information
`should be the last step in a user session(i.c., in the bbroot-
`session script). As a default, no processes with the specific
`user IDs, userX (e.g., user0), should remain after userX has
`exited from the system. An optional script for running tasks
`on the system maybe provided to allow certain user-specific
`information to remain on the system after the user has
`exited.
`
`[0059] Dynamic User Context
`[0060]
`In one embodiment, the user interface requires a
`local user context. Before the user interface is initiated, a
`local user context is dynamically generated for the user(i.e.,
`automatically selected from a preset pool of reserved user
`contexts). FIG.8 illustrates the process of initiating a user
`interface in accordance with one embodimentof the present
`invention. At block 800, a user requests to connect to a
`computer system. At block 810, a local user context is
`dynamically generated for the user. The local user context
`may include preferences suchas font settings. At block 820,
`a user interface is initiated using the local user context for
`the user.
`
`In one embodiment, some of the user context data
`[0061]
`is downloaded from the system to the local machine and
`
`incorporated in the local user context. In another embodi-
`ment, the local machine contains default user context data.
`The default user context data is incorporated in the local user
`context. In one embodiment, if the user context data on the
`system is unavailable, a default local user context is gener-
`ated from the default user context data.
`
`FIG.9 illustrates the process of generating a local
`[0062]
`user context and initiating a user interface in accordance
`with one embodimentof the present invention. At block 900,
`a user requests to connect to a computer system. At block
`910, it is determined whether the user context data on the
`system is available. If the user context data on the system is
`available, user context data is downloaded from the system
`at block 920. At block 930, the user context data from the
`system is combined with default user context data stored at
`the local machine to generate a local user context and the
`process continues at block 950. If the user context data on
`the system is not available, the default user context data
`stored at the local machine is used to generate a local user
`context at block 940. The process then continues at block
`950. At block 950, a user interface is initiated using the local
`user context for the user.
`
`[0063] Altering User Contexts
`
`In one embodiment, the user maypersistently alter
`[0064]
`a portion of the user context data from the system. After the
`context data is altered, the altered data is uploaded to the
`system. FIG. 10 illustrates the process of persistently alter-
`ing user context data in accordance with one embodiment of
`the present invention. At block 1000, user context data is
`downloaded from the system. At block 1010, a local user
`contextis generated using the downloaded user contextdata.
`
`[0065] At block 1020,a user interface is initiated using the
`local user context. At block 1030, the user alters part of the
`user context data that is stored on the system. At block 1040,
`the user logs out and the altered user context data is
`uploaded to the system for persistent storage.
`
`In another embodiment, the user may temporarily
`[0066]
`alter a portion of the default user context data on the local
`machine. When the user stops using the system (e.g., logs
`out), the temporary alterations are lost and the default user
`context data is restored. In another embodiment, the user is
`prevented from altering some portions of the user context.
`
`[0067] FIG. 11 illustrates the process of altering a user
`context in accordance with one embodiment of the present
`invention. At block 1100, a local user context is dynamically
`generated. At block 1110, a user attempts to alter an aspect
`of the local user context. At block 1120,
`it is determined
`whether the user is allowed to alter the aspect of the local
`user context. If the user is not allowed to alter the aspect of
`the local user context, the permission to alter the aspect is
`denied at block 1130 and the process continues at block
`1170.
`
`If the user is allowedto alter the aspect ofthe local
`[0068]
`user context, it is determined whetherthe useris allowed to
`persistently alter the aspect of the local uscr context at block
`1140. If the user is not allowedto persistently alter the aspect
`of the local user context