Fine-Grain Access Control for Securing Shared Resources …rblee/ELE572Papers/finegrainAccessGRID.pdf · Fine-Grain Access Control for Securing Shared Resources in Computational Grids*

Fine-Grain Access Control for Securing Shared Resources in

Computational Grids*

Abstract

Computational grids provide computing power bysharing resources across administmtive domains. Thissharing, coupled with the need to execute untrustedcode from arbitmry users, introduces security hazards.This paper addresses the security implications of mak-ing a computing resource available to untrusted appli-cations via computational grids. It highlights the prob-lems and limitations of current grid environments andproposes a technique that employs runtime monitor-ing and a restricted shell. The technique can be usedfor setting-up an execution environment that supportsthe full legitimate use allowed by the security policy ofa shared resource. Performance analysis shows up to2.14 times execution overhead improvement for shell-based applications. The approach proves effective andprovides a substmte for hybrid techniques that combinestatic and dynamic mechanisms to minimize monitor-ing overheads.

Key Phrases: access control, grid environments,grid security, Unix access model.

providing an active enforcement of the security policyof the shared resources. This requirement, if not ad-dressed, presents significant obstacles to the viabilityof computational grids, which typically span multipleadministrative domains.

The ability to share resources is a fundamental con-cept for realization of grids; therefore, resource se-curity and integrity are prime concerns. If the goalis to allow arbitrary users to submit applications tothe grid, new dimensions to security issues will beintroduced [2]. The issues of authorization and se-cure communications are addressed in great length inGlobus [www .globus.org] .However, in this case, thefact that the users and resources no longer enjoy a mu-tual relationship complicates the problem. Two scenar-ios may arise, the shared resource may be malicious andaffects the results of the program utilizing the resource,or the grid program may be malicious and threatensthe integrity of the resource. Although the first sce-nario is a crucial issue [25] , this paper focuses on thelatter issue providing a step towards achieving better

security.A two-Ievel approach consisting of a restricted shell

and runtime monitoring is presented, to provide a se-cure execution environment for unmodified binaries.The second level provides active runtime monitoringto prevent any malicious use in programs. However ,development environments generally require an inter-active shell environment. H only runtime monitoringwere to be employed, the shell itself will also haveto be monitored therefore incurring extra overheads.To overcome these overheads, the first level of the ap-proach consists of a restricted shell that is not moni-tored directly by the second level. The shell utilizes itsown checks to control the user's ability to freely peruseresources during an interactive session. For example,the shell controls reads to otherwise world-readable re-

1. Introduction

Grid environments of the future will require an abil-ity to provide a secure execution environment for ap-plications. The Grid should allow arbitrary code fromuntrusted users to legitimately share resources, while

*This work was partially funded by the National ScienceFoundation under grants ECS-9809520, EIA-9872516, and EIA-9975275, by the Army Research Office Defense University Reosearch Initiative in Nanotechnology, and by an academic rein-vestment grant from Purdue University. Intel, Purdue, SRC,and HP have provided equipment grants for PUNCH compute-servers.

Proceedings of the International Parallel and Distributed Processing Symposium (IPDPS�02) 1530-2075/02 $17.00 © 2002 IEEE

standard Web browsers (see www.punch.purdue.edu).As in typical grid environments, users in PUNCH arealso transient and mostly utilize the system for specificprojects. Usage policies associated with machines arecomplex and often change. The diversity of PUNCHusers and applications has significant value in terms ofvalidating research concepts and simulations. However ,operating and supporting such a service in a researchenvironment is impractical unless the administrativecost of maintaining security is kept under control.

In this context, there are two categories of grid ap-plications. There are applications that are provided bythe grid-service providers for use-only purposes. Usershave very restricted access to these applications andcannot do much damage. However, a more challengingscenario is presented by research applications that aretypically submitted by the users, and no safety guar-antees can be provided for the behavior of these appli-cations.

3. Grid Security

From a security standpoint, the users the applica-tions, or the grid middleware -or some combinationof the three -must be trusted. In dynamic, scalable,wide-area computing environments, it is generally im-practical to expect that all users can be held account-able for their actions. Accountability comes after thedamage has been done, making this a costly solution.Another option is to trust the applications. This is typ-ically accomplished either by constraining the develop-ment environment to a point where the generated ap-plications are guaranteed to be safe or by making surethat the applications come from a trusted source. How-ever, limiting the functionality of applications also lim-its the usefulness of the computing environment. His-tory has shown that it is too easy for applications fromtrusted sources to contain bugs that compromise theintegrity of resources. Grid applications can be classi-fled, as shown in Figure 1, based on the entity trustedfor guaranteeing safety of grid applications, and thecorresponding limitations imposed on allowed grid ap-plications. At the origin of the plot, we have the idealgrid environment that allows the execution of arbitrarylegal code from untrusted users while preventing illegalcode from causing damage. Systems such as PBS [4] ,GLOBUS [10], and Sun Grid Engine [24] only allowaccountable users. During the application generationprocess, safety checks can be implemented at the sourcecode level (by using a safe language), at compile-timeor at static link-time (as in Condor [18]). The spacebetween the region where access checks are applied andexecution time indicates the window of opportunity

sources and access to arbitrary directories. The ex-perimental measurements of execution time overheadsfor various shell-based applications show that the two-level technique is up to two times faster than runtimemonitoring alone.

'lraditional methods of controlling access to com-puting resources are based on choosing a principal [22] ,an entity responsible for usage and actions of the re-sources. In UNIX-based systems, this assignment isdone by creation of an account for users. The processof assigning such user accounts serves two purposes:1) it helps to ensure that users are responsible for theiractions (for example, by obtaining personal and contactinformation for each user) j and 2) it allows administra-tors to enforce usage policies (for example, by not giv-ing out accounts on certain machines). The logisticaloverheads associated with manual account creation andmaintenance become overwhelming when this approachis extended to grid environments. Dynamic and tempo-rary usage, which will constitute a vast majority of gridusers, may be precluded by these overheads. Anotherproblem is that resource owners must implicitly rely onthe accountability of the users of the resources, makingit difficult and imprudent for resource owners to shareresources outside their administrative domains. An-other issue results from the inability of resource own-ers to control how users employ the resources. Forexample, resource owners may want some users to useonly certain machines for specified applications, how-ever given the conventional account paradigm, there isno easy way to enforce this.

The rest of the paper is organized as follows. sec-tion 2 presents a description of the various require-ments of grid applications and the premises that un-derlie this investigation. Section 3 describes the var-ious approaches adopted by current grid systems andthe shortcomings associated with providing a secureexecution environment. Section 4 describes an onlinetechnique to implement access control that can sup-port arbitrary code from untrusted users. Section 5provides a brief discussion of other techniques that canbe used to provide the necessary execution environ-ment required for grid applications. Finally, Section 6presents concluding remarks.

2. Background

Although this work is applicable to generic grid envi-ronments, the implementation observations were con-ducted in the context of Purdue University NetworkComputing Hubs (PUNCH) [16] that is a platform forgrid computing that allows users to access and rununmodified applications on distributed resources via


I Point of" trust II Restrictions I IssUes I.Entire ProceM Safe APls Overhead for

Examples: Requires adaptingEntropia, application source application toDistributed.net, Trusted grid.SetiQHome programmer, Legacy binaries

compiler, linker not supported.Human Problem. withinteraction arbitrarily

trusting athird-party.J!:xponentialbinary codebloat(PCC).Overhead ofanalysis may notbe justified.Application canbe tampered withat a later stage.Legacy binariesnot supported

Aun4ime Awl~n ;SIalic Linking ~iiing SOUrce ~ ; End Users

E11virOllment .xec~es !--Ap~alion Generalion Process~

Trusted Entities

Figure 1. Classification of grid environments

Table 1. Access control techniques adoptedby grid environments, the corresponding re-strictions on allowed code/applications andthe associated issues

policy are not permitted, only due to coarse grain ofcontrol. This limits the functionality of applicationsmore than that could be supported on the host. Thedifference in what is allowed to an application and whatis permitted by the host security policy is a function ofthe grain of control, and therefore can serve as quanti-fying criteria for a comparison of relative effectivenessof the various schemes.

when an application can be tampered with to intro-duce malicious behavior. Grid environments, such asDistributed.Net [5] , Entropia [6] , and SETI@Home [23]control the entire application generation and deploy-ment process. Though the grid users are not account-able, the grid-service providers implement or check theapplication on behalf of these users and are liable intheir stead. The top rectangle covering many phasesof application generation indicates the large amount ofthird-party software that needs to be trusted by theshared resources. Shadow accounts with runtime mon-itoring in PUNCH [15] and generic virtual machines,such as VMWare [26], can apply the access-controlchecks at runtime to support arbitrary code and un-trusted users.

The future grid environments will be as close to theorigin as possible in order to provide legitimate re-source sharing to arbitrary unmodified binaries. Con-sequently security is best achieved by way of activeenforcement of policies within grid middleware layers.

For an application to function properly, it should beprovided with an execution environment on a remotehost that grants the least-required privileges, based onthe principle of least privilege [22]. However, the leastrequired privilege of an application might require moreaccesses than a shared resource is willing to provide. Inmost cases, lack of fine grain control mechanism forcesthe grid-service providers to be conservative. Applica-tions that can be run on a host with a given security

3.1. Trusted Applications

Table 1 summarizes the techniques adoptedby current grid environments for trusting appli-cations, the corresponding restrictions on allowedcode/applications, and the associated security issues.

The approach adopted by grid-service providerssuch as Distributed. Net [5], Entropia [6], andSETI@Home [23], is only to accept code from a trustedsource and control the entire development process -

generation to deployment -of a grid application. Thecode that actually runs on the target host is guaranteed


Figure 2. Sample grid application code thatcan invoke the malicious code at run time. Itbypasses the system-calllibrary and invokesfork ( ) and exec ( ) via the kernel.

voking the malicious code is relatively easy comparedto a general case where execution requires knowledgeof loopholes in the target application. The goal of thiscode is to access a resource that is protected by the gridsecurity enforcement. The left panel shows a snippet ofC code that is safe except for the explicit cast of a datapointer to a function pointer (also a legal C operation).It loads a file into memory and executes it. The rightpanel shows a piece of malicious machine code that isunavailable at compile-time, but is injected into the ex-ecution stream. The machine code, in essence, executesthe fork() and exec() system-calls using system trapinterrupt.

These system-calls were chosen as representative ofmalicious behavior, because if arbitrary access is al-lowed to these system-calls, all operations allowed to alocal user can be done on the machine executing thecode. The malicious nature of the code is not de-tectable; even when compiled using special librariesthat do not allow the said system-calls because of theabsence of the malicious part at compile-time.

The static checks can be extended by incorporatingproof-carrying codes [20] , enforcing security checks atlink-time, or at load-time. But due to the absence ofany run-time checks, these approaches remain suscep-tible to the malicious code of Figure 2, because the codedoes not rely on specific libraries and calls the kernel di-rectly at run-time. Such codes practically render thesesecurity checks insufficient. Finally, for techniques im-plemented via trusting applications, the source coderequirement precludes legacy binaries.

4. Proposed Approach to Grid Security

The analysis of current approaches shows that theinjection of malicious code into an otherwise secure ap-plication cannot be detected offline using static meth-ods. In order to support arbitrary user-submitted ap-plications, irrespective of the language and compilerused to produce them, an execution environment on thehost machine is necessary to meet the security require-ments. Runtime monitoring of the system-calls traceof an application can provide control over the arbitraryaccesses of an application. However, development en-vironments generally require an interactive shell en-vironment. Runtime monitoring alone of all the ap-plications, including the shell, incurs extra overheads.To avoid these overheads, a two-Ievel approach is pre-sented: level-one to handle interactive shell sessions,and level-two to handle arbitrary (user-submitted) ap-plications.

to be safe by grid-service providers.This typically implies that applications have to be

rewritten and prepared for the grid, which in turnrequires that the programmer, compiler, linker, andloader must all be trusted. Such incurred adaptationoverhead may be large, hence limiting the rate at whichnew applications are deployed. Moreover, if a trustedsource is the only protection for a host system, a breachon the source side can affect all resources. This placesvery stringent security requirements on the source.

The compiler has access to the source code and canperform static analysis to determine code that can pos-sibly infringe on the host security policy. However, inthe absence of runtime checks, the most a compiler cando is to either allow or disallow certain actions basedon this analysis. The security enforced in this man-ner has the drawback that if a malicious piece of codeis imported into the program, the security checks caneasily be avoided.

A dynamic library that allows runtime modificationof a process to act maliciously is described in [19] , a se-curity breach in context of Condor [18] is provided asan example. It also provides a list of probable meth-ods for preventing such a breach, however, no actualprevention technique is described. In the following dis-cussion, it is shown that the process behavior can alsobe modified in a simple way that does not require so-phisticated libraries. Moreover, a solution that over-comes the limitations of the current approaches is alsoproposed in the next section.

Figure 2 shows a grid application code that doesa stack-smashing attack [1] on its own stack. In thiscase, since the grid user owns the target process, in-


Figure 3. An illustration of modules and inter-actions in the two-Ievel approa'ch.

4.1. The Tw()-level Approach

In case access to one or more of the required files (or theexecutable) is not specifically granted to the user, thecommand is not allowed to complete. Even for allowedcommands, the set of checks implemented in level-twoare not completely disabled. However, before actualexecution of a permitted application, the shell informslevel-two to set up proper monitoring mode, based onthe configuration policy for the application. In case ashell script is executed, each line is separately parsed,and the shell checks can allow or deny the commandson per line bases.

For sandboxing the user under the control of the se-curity module, the restricted shell is made the defaultshell, and execution of other shell binaries is prohib--ited. For instance, during an interactive session, therestricted shell is capable of locking the user in a pre-specified directory and preventing reads to arbitrarywor!d-readable files by the remote users. When ar-bitrary or user-developed programs are executed, theshell can no longer control the accesses, as programscan access resources maliciously via direct calls to thekernel. This is also the case when scripts written in lan-guages such as Per! are executed. Level-two controlsall the applications spawned by the shell.

The heart of level-two is the process-tracing ca-pabilities in modern UNIX/LINUX systems providedby the ptrace systems-call and the /proc file-system.This functionality allows a parent process to keep acheck on its child process and modify the behaviorof the child process [8]. There have been several at-tempts [3, 11, 14] to intercept system calls made by anapplication and modify the behavior to enforce host se-curity policies. J anus [28] is also an example of such atechnique. Once the system calls trace is obtained, thetechniques discussed in [9, 17, 27] can be employed toascertain whether the application is behaving in a mali-cious manner. The design oflevel-two is based on sim-ilar methods. However, the use of level-one serves twopurposes. First, for shell-based applications it avoidsthe extra overheads of monitoring the shell itself. Sec-ondly, the shell provides a mechanism to switch moni-toring modes of level-two on per application basis dur-ing runtime. For example, an application provided bythe system may be allowed to access certain directories,whereas an application provided by a user may not.

Grid middleware initially configures level-two withtwo or more sets of system-calls, those which shouldalways be monitored for proper operation of the moni-toring module, for instance fork(), and those specifiedin host security policy as malicious and should be moni-tored for all applications other than the restricted shell,for instance exec ( ) .socket ( ) .At startup, the mon-itor defaults to monitoring the first set of calls, switch-

Figure 3 shows the block diagram of the two-level approach, comprising of a restricted shell and asystem-call monitoring module. The shell consists ofa standard command shell augmented with a securitymodule that actively checks the commands issued bythe grid user. The module, via these checks, enforcesthe host security policy. The policy is specified in aconfiguration file containing a list of options, such asallowing executables from user-directory or directorychange privilege to directories outside home directoryhierarchy, and a template containing allowed executa-bles, accessible files, allowed directories outside homedirectoryetc. These constraints can be captured ei-ther explicitly by specifying a list or implicitly by usingwildcards.

The file can be configured to be either an allow list( default behavior) or a deny list, where access to spec-ified resources is either allowed or denied respectively.Grid middleware can configure the security module ac-cording to the needs and privileges of individual gridusers by providing a proper configuration file. On ini-tialization of each session, the module reads this file foroptions and then bases its decisions on them.

The restricted shell works by breaking down a userissued command into two parts, the actual executablename and a list of files that are required for completionof the command. A match of the executable name tothe pre-configured specifications is then searched, fol-lowed by a similar matching for the list of required files.


control and executes the application. Level-two thenstarts monitoring calls. The approach proves effec-tive by detecting the calls and terminating the mali-cious process. Attacks such as unauthorized informa-tion gathering) monitoring of other users) undermininglocal systems) and arbitrary communication to remoteresources are prevented as they require the ability tofreely access the world-readable resources; an activitythat can easily be restricted by specifying the allowedresources and monitoring the system-calls to enforcethe policy.

Figure 4 shows performance overheads of the two-level approach, observed utilizing a set of syntheticbenchmarks consisting of a program with repeatedfork( ) calls, a program with successive pairs of open( )and close ( ) calls, a typical shell session emulation,and a typical run of Spice. Execution time for each setof benchmark was observed for three cases: withoutany monitoring) with monitoring alone, and with theproposed two-Ievel scheme. The overhead is computedas a ratio of the execution time of two monitoring meth-ods to the normal execution time without monitoring.

Since the fork() system-call has to be interceptedfor each occurrence, the first set of observations showsthe effects of monitoring on a program that is composedof 200 fork() calls. The purpose of this run is to deter-mine a worst case bound on runtime monitoring over-head. From 1000 observations, an average overhead of2.59 times was observed for proposed approach as com-pared to 2.64 times for full monitoring. The more thantwice overhead is due to an extra fork ( ) call made bythe monitoring module for each fork() call executedby the program, as well as the processing time of thesystem-call monitoring module to determine what ac-tions to take on specific system-calls. In typical appli-cations the frequency of fork() calls is much smallerthan other system-calls. The overhead of a fork ( ) callhas a small effect on the overall performance of the ap-plication. Moreover, the difference in the overheads offull-monitoring and the proposed scheme is due to thefact that runtime monitoring alone monitors the shellas well, where as the proposed scheme does not.

Another set of results consists of 1000 observa-tions) obtained for 200 pairs of successive open() andclose() calls on a file. Here the purpose is to deter-mine the effect of monitoring on innocuous calls. In thisscenario, because the calls are not being intercepted,the average overhead is 1.01 for both runtime monitor-ing and the proposed scheme. For this scenario, filecaching may affect the time taken by the open() andclose() calls. The relative effect remains the same onboth sets of observations. This run shows that runtimemonitoring alone or with in the proposed scheme in-

Figure 4. Performance results of the two-level approach, showing comparative execu-tion times for various synthetic.-benchmarksused for observations.

ing to another set of higher monitoring, only when anapplication is executed as indicated by the restrictedshell. The monitor works by passively waiting until anapplication invokes a call that is not permitted. Whensuch a call is invoked, the kernel system-call mecha-nism transfers control to the security module that canthen analyze the call and inform the kernel of whetheror not to allow the action to complete. In case thecall is permitted, it is allowed to complete, and con-trol is finally given back to the application. Otherwise,the application is returned an abort flag, or even ter-minated if it continues executing the same restrictedsystem-call. If the fork() system-call is allowed, itis always monitored, and a companion monitoring pro-cess has to be spawned for every child spawned by anapplication. This is necessary for preventing an appli-cation from spawning unmonitored children that cancreate security hazards.

4.2. Performance Analysis

Two aspects of the approach are discussed, the effec-tiveness in preventing malicious program behavior, andthe execution overhead for shell-bas(~d applications ascompared to runtime monitoring only.

The tw0--Ievel approach avoids the ill effects of user-contributed binaries discussed earlier. For example,when the code of Figure 2 is executed on a systemconfigured to prevent the fork() and exec() calls,level-one signalslevel-two that the shell is no longer in


gram. The restricted shell of level-one provides a steptowards this goal. Such schemes are currently being in-vestigated to determine whether they can be employedefficiently in the grid environment.

5. Discussion

It is clear from the presented scenarios that theUNIX kernel is not designed for the tasks that are re-quired in the execution of remote code in grid environ-ments. The proposed solution has relied on user-modetechniques in order to avoid modifications to the ker-nel. Redesigning the required portions of the kernelmay provide more efficient solutions to the investigatedIssues.

Finer-grain access-control in the form of access-control lists is evolving in the Unix kernel that allowsa finer-grain user access-model. The access-controllist approach is not suitable to the presented scenariobecause it modifies properties associated with the re-source rather than the user [7] .The functionality re-quired for setting-up an execution environment for gridapplications is a means for a user to specify the listof resources to which access is allowed or denied onper-process-basis that, in essence, leads to a capabilitymodel.

Another approach for addressing the described se-curity issues is the use of a virtual machine, such asthe sandbox of Java Platform [12]. For grid environ-ments, the need to write J ava code, or port applicationsto Java platform can be eliminated by a virtual ma-chine that is decoupled from applications. Examplesof application-independent virtual machines includeIBM's Virtual Image Facility [13} and VMware [26].These systems support sandboxing at the level of op-erating systems and can provide a substrate for exe-cuting arbitrary untrusted code without compromisingthe host machine security.

6. Conclusions

The paper shows that the execution environmentrequired for allowing user-developed arbitrary binariesto run on shared resources entails a more constrainedview of the system than provided by the traditionalUnix environment. The access-control model is notenough to handle the security hazards introduced byshared resource usage in dynamic, large-scale grid en-vironments. The proposed approach is to employ run-time monitoring and process-tracing that allows onlypermitted actions. In an attempt to minimize the run-time monitoring overhead, a secure restricted shell is

cur negligible overheads for unmonitored calls. Hence,if the shell can determine and chan!~e modes of mon-itoring on per application basis, the overall effect ofmonitoring can be minimized.

Next is a shell script that emulates an interactiveshell. It was executed 1000 times and measurementswere taken for each case of no monitoring, runtimemonitoring with a standard shell, and under the pro-posed scheme. The overhead of molnitoring on mali-cious actions that can be determined via the shell isevident from the figure, 1.07 times ov'erhead due to theproposed scheme as compared to the 2.29 times over-head of monitoring all system calls -a improvement of2.14 times. This improvement is du,~ to the fact thatthe shell employs exec() and fork() system calls forexecution of each command in the s<:ript. In case of astandard shell, these calls are monitored by level-twoand as measured earlier incur large overheads, whereas in the restricted shell they are not, hence the gainin performance.

Another typical application on PUNCH isPROPHET, a simulator for sol"ing systems ofpartial differential equations. It has a shell interface,and hence pose a problem when arbitrary usersare allowed to access the shell. However, when therestricted shell replaces the default shell, and a policyof minimum system calls is employed, the risk ofan arbitrary user freely accessing: local resourcesis eliminated. In a typical run, negligible securityoverhead is observed, partially because the secure shellreplaces the default shell and has similar runtimes, andpartially due to the fact that malicious calls do notoccur in typical runs, and thereforc~, the monitoringmodule remains dormant.

In the last set of observations, Spice, a commonlyused application, is executed to plot voltage/currentcharacteristics of a Nanoscale MOSFET (a typical ap-plication on PUNCH). As Spice does Illot make any ma-licious calls in its legal execution, th,e execution timeswith or without system-call monitoring, and with theproposed scheme are almost the same with only 1.06times overhead. As Spice is not necessarily a shell-based application, the proposed scheme behaves simi-larly to runtime monitoring alone.

The results show that interceptin!~ system-calls in-troduce a significant overhead, and there is a need forminimizing the number of calls thai; are intercepted.Static schemes as discussed in [21, 29] have the ca-pability to determine unsafe portions of code by ex-tended program analysis. Hence, som'e of these schemescan be leveraged in the present setting for minimizingthe overhead of runtime checking, b;y selecting differ-ent monitoring modes for different portions of the pro-


utilized that avoids the process-tra~ing overhead ofthe shell environment itself. The pJroposed two-levelapproach provides a reduction of up to 2.14 times inexecution-time overheads for shell-based applicationsas compared to monitoring alone. In the future, hy-brid techniques to minimize the number of system-callsmonitored, as well as virtual machines can also pro-vide an appropriate execution environment. Virtualmachines that can efficiently provide desired environ-ments are a nascent technology and may become keyplayers in the long run.

References

[1] N. S. A. Baratloo and T. Tsai. Tr,!I.Ilsparent run-timedefense against stack smashing attcLcks. In Proceedingsof the USENIX Annual Technical Conference, pages207-233 June 2000.

[2] S. Adabala, A. R. Butt, R. J. Figueiredo, N. H. Ka-padia, and J. A. B. Fortes. SecuIity implications ofmaking computing resources available via computa-tional grids. Technical Report TR~-ECEO1-2, PurdueUniversity, West Lafayette, IN, September 2001.

[3] A. D. Alexandrov, M. Ibel, K. E. ~;chauser, and C. J.Scheiman. Ufo: A personal global file system basedon user-Ievel extensions to the opeTating system. vol-ume 16, pages 207-233, August 19!~8.

[4] A. Bayucan, R. L. Henderson, C. Lesiak, B. Mann,T. Proett, and D. Tweten. Portable batch system: Ex-ternal reference specification. Tecllllical report, MRJTechnology Solutions, November 1!~99.

[5] Distributed Computing Technologies Inc.

http:/ /www.distributed.net[6] Entropia Inc. http:/ /www.entropia.com[7] EROS-OS. Comparing ACLs and Capabilities

http:/ /www.eros-os.org/essays/acllwcaps.html[8] S. E. Fagan. Tracing bsd system calls. Dr. Dobb's

Journal, pages 38-43, 03 1998.[9] S. Forrest, S. A. Hofmeyr, A. SoJlIlayaji, and T. A.

Longstaff. A sense of self for Unix processes. In Pro-ceedinges of the 1996 IEEE Symp,osium on Researchin Security and Privacy, pages 120-128, 1996.

[10] I. Foster and C. Kesselman. Globus: A metacomput-ing infrastructure toolkit. The International Journalof Supercomputer Applications and High PerformanceComputing, 11(2):115-128, Summer 1997.

[11] I. Goldberg, D. Wagner, R. Thomas, and E. A.Brewer. A secure environment for untrusted helperapplications: Confining the wily hacker. In Proceed-ings of the 6th Usenix Security Syrnposium, San Jose,Ca., 1996.

[12] L. Gong, M. Mueller, H. Pr;liullchandra, andR. Schemers. Going beyond the san.dbox: An overviewof the new security architecture in the java develop-ment kit 1.2. In USENIX Symposium on InternetTechnologies and Systems, 1997.

[13] IBM Corporation. White Paper: Sj390 Virtual ImageFacility for Linux, Guide and Reference. GC24-5930-03, February 2001.

[14] M. B. Jones. Interposition agents: Transparently in-terposing user code at the system interface. In Sym-po8ium on Operating Sy8tem8 Principle8, pages 80-93,1993.

[15] N. H. Kapadia, R. J. Figueiredo, and J. A. B. Fortes.Enhancing the scalability and usability of computa-tional grids via logical user accounts and virtual filesystems. In Heterogeneous Computing Workshop atIPDPS, April 2001.

[16] N. H. Kapadia, R. J. Figueiredo, and J. A. B. Fortes.Punch: Web portal for running tools. In IEEE Micro,May-June 2000.

[17] C. Ko, M. Ruschitzka, and K. Levitt. Execution mon-itoring of security-critical programs in a distributedsystem: A specification-based approach. In Proceed-ings of the 1997 IEEE Symposium on Security andPrivacy, Oakland, California, 1997.

[18] M. J. M. J. Litzkow, M. Livny, and M. W. Mutka.Condor -A hunter of idle workstations. In Proceed-ings of the 8th International Conference on DistributedComputing Systems (ICDCS), pages 104-111, Wash-ington, DC, 1988.

[19] B. P. Miller, M. Christodorescu, R. Iverson, T. Kosar,A. Mirgorodskii, and F. Popovici. Playing insidethe black box: Using dynamic instrumentation tocreate security holes. Parallel Processing Letters,11(2,3):267-280, 2001.

[20] G. C. Necula and P. Lee. Safe kernel extensions with-out run-time checking. In USENIX, editor, 2nd Sym-posium on Operating Systems Design and Implemen-tation (OSDI '96), October 28-31, 1996. Seattle, WA,pages 229-243, Berkeley, CA, USA, 1996.

[21] H. Patil and C. N. Fischer. Efficient run-time mon-itoring using shadow processing. In Automated andAlgorithmic Debugging, pages 119-132, 1995.

[22] J. H. Saltzer and M. D. Schroeder. The protection ofinformation in computer systems. Proceedings of theIEEE, 63(9):1278-1308, 1975.

[23] SETI Institute Online http:j jwww.seti-inst.eduj science j setiathome.html

[24] Sun (tm) Microsystems Sun Grid Enginehttp:j jwww.sun.cajsoftwarejgridwarej

[25] G. Vigna, editor. Mobile Agents and Security, volume1419 of LNCS. Springer- Verlag, June 1998.

[26] VMware Incorporated. VMware GSX Serverhttp:j jwww.vmware.com, 2000.

[27] D. Wagner and D. Dean. Intrusion detection via staticanalysis. In Proceedings of the 2001 IEEE Symposiumon Security and Privacy, May 2001.

[28] D. A. Wagner. Janus: an approach for confinementof untrusted applications. Technical Report CSD-99-1056, 12, 1999.

[29] R. Wahbe, S. Lucco, T. E. Anderson, and S. L.Graham. Software fault isolation. In FourteenthACM Symposium on Operating System Principles, vol-ume 27, pages 203-216, December 1993.


Documents

Fine-Grain Access Control for Securing Shared Resources …rblee/ELE572Papers/finegrainAccessGRID.pdf · Fine-Grain Access Control for Securing Shared Resources in Computational Grids*