Fine-Grain Access Control for Securing Shared Resources rblee/ELE572Papers/  

  • View
    213

  • Download
    0

Embed Size (px)

Text of Fine-Grain Access Control for Securing Shared Resources rblee/ELE572Papers/  

  • 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 (IPDPS02) 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

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

  • 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/ap

View more >