Using Firewalls to Enforce Enterprise-wide Policies - ResearchGate

Using Firewalls to Enforce Enterprise-widePolicies over Standard Client-Server Interactions

Tuan Phan, Zhijun He, Thu D. NguyenDepartment of Computer Science, Rutgers University, New Brunswick, USA

Email: {tphan, zhijun, tdnguyen}@cs.rutgers.edu

Abstract— We propose and evaluate a novel framework forenforcing global coordination and control policies over mes-sage passing software components in enterprise computingenvironments. This framework combines the use of firewalls,both per-node software and dedicated firewalls, with anexisting coordination and control system to enforce policiesthat, among other properties, are stateful and communal.The firewalls act as a set of distributed reference monitorsthat filter messages exchanged between the interactingsoftware components. The coordination and control systemcoordinates the firewalls to enforce a specific set of policies,passing only messages allowed by these policies. Filteringdecisions may be based on credentials presented to thecoordination and control system as well as system stateaccumulated over time. This filtering approach decouplescoordination and control from application implementation,allowing the coordination and control mechanism and ap-plication implementations to evolve independently of eachother. We demonstrate the power of our framework by usingit to specify and enforce an RBAC policy with delegation,revocation, and separation-of-duty over accesses to a clusterof NFS and SMB file servers without changing any clientor server implementations. Measurements show that ourframework imposes acceptable overheads when enforcingthis policy.

Index Terms— coordination and control, access control, ref-erence monitor, firewall, communal policies, stateful policies

I. INTRODUCTION

Today’s enterprise computing environments are increas-ingly comprised of heterogeneous components not con-structed according to any single system design. Rather, in-dependently constructed components are composed underthe assumption that they will interoperate harmoniouslybecause they implement standardized interaction proto-cols. Unfortunately, these components often do not workwell together despite their adherence to standards because:(1) standards often define the mechanisms for interactionbut provide little support for governing interaction, and(2) standards always leave some implementation detailsunspecified and so different implementations of the samestandard are not always fully compatible. To exacerbate

This paper is based on “Enforcing Enterprise-wide Policies over Stan-dard Client-Server Interactions,” by Z. He, T. Phan, and T. D. Nguyen,which appeared in the Proceedings of the 24th IEEE Symposium onReliable Distributed Systems (SRDS), Orlando, USA, October 2005.c© 2005 IEEE.

This work was supported in part by NSF grants EIA-0103722 andCNS-0448070.

the problem, as personal devices proliferate, many orga-nizations are being forced toward a decentralized controlmodel, where shared infrastructures are maintained byprofessional staffs but personal devices are managed bytheir individual owners. Thus, even the composition of theenterprise system may not be well defined and understood.Needless to say, these systems are unreliable, insecure,and difficult to use and maintain [1]–[3].

A number of research efforts have sought to addressthe above problem by introducing mechanisms to enforceexplicit policies that coordinate and control the activitiesof the disparate components within such environments,e.g., [4]–[7]. Unfortunately, many of these mechanismsrequire the modification of existing software, which lim-its their applicability and slows their adoption. In thispaper, we propose a novel approach for applying thesemechanisms to software components that interact usingstandardized message passing protocols without requiringany changes to the applications. Our approach also allowsnew applications to be developed that are neutral withrespect to specific coordination and control frameworks,effectively decoupling coordination and control from ap-plication implementation.

Specifically, we observe the ubiquitous presence of fire-walls in today’s computing environments, including per-node software firewalls and dedicated firewalls embeddedwithin the networking infrastructure. Our approach usesthese firewalls together with a packet analyzer and a trustmanagement system called KeyNote [4] to implementa set of distributed reference monitors. These referencemonitors are able to intercept all packets sent to/from eachnode and reconstruct them into protocol-level messagesthat should be subjected to enterprise-wide policies. Wethen use an existing coordination and control systemcalled Law Governed Interaction (LGI) [6] to coordinatethe reference monitors to enforce specific global policies,passing only the messages that are allowed by thesepolicies and blocking all others.

We give an overview of our framework and explain howthe above components fit together in Section III, after wehave presented an example policy in Section II to provideconcrete context for the description. For now, we observethat the resulting mechanism can be used to explicitlyspecify and enforce policies that, among other properties,are stateful and communal. Stateful policies are those

JOURNAL OF COMPUTERS, VOL. 1, NO. 1, APRIL 2006 1

© 2006 ACADEMY PUBLISHER

that are sensitive to the history of interactions. Examplestateful policies include those encapsulating coordinationand control principles such as delegation and revocation,as well as the Chinese Wall policy [8]. Communal policiesprovide for control decisions to be based on state accu-mulated across a community of interacting components,rather than just state accumulated at each individualcomponent.

We demonstrate the power of our framework by usingit to coordinate and control two access problems: (1) ac-cesses from wireless devices to an enterprise’s networkedservice infrastructure, and (2) accesses to a specific setof file servers. Access control is a good representativeproblem because while a large body of research hasaccumulated to argue the importance of principles suchas delegation and revocation [4], [9], [10], separationof duty, and auditing [11], most existing access controlmechanisms are still based on the access control matrixmodel, where large parts of the matrix are manuallymaintained by system administrators. For example, inUNIX, a simple coordination problem such as sharing aset of files between two people, say a professor and hisTA, requires the intervention of a system administrator toset up and later remove a group. This can often lead toinappropriate control that can adversely affect the securityof the system, e.g., the professor making his files world-accessible to share with his TA or the group remainingdefined long after the interaction has ended.

Further, in today’s client-server applications, accesscontrol is typically established by individual servers,where the policy and its enforcement are embedded inthe code of the server. This server-centric approach hasnumerous disadvantages, including: (1) the difficulty ofchanging the policy and evolving the access controlmechanism; (2) the lack of uniformity in what policies areenforced and enforceable by different servers; and (3) theinability to enforce communal policies—the revocation ofaccess rights provides a ready example where communalaccess control is needed: it is often easier to detectclient misbehavior by observing a client’s interactionswith multiple servers as opposed to individual pair-wiseclient/server interactions.

Thus, we describe how our framework can be used tospecify and uniformly enforce the policy introduced inSection II, which is a role-based access control (RBAC)policy with delegation, revocation, and separation-of-duty,across a community of NFS and SMB (SAMBA) fileservers. We also quantify the performance overheadsimposed by our framework, showing that the enforcementof our policy can incur non-trivial but (in our opinion)acceptable overheads.

In summary, our contributions include: (1) defining aframework for enforcing sophisticated coordination andcontrol policies over communities of interacting softwarecomponents that works external to the implementationsof these components; this decoupling of coordination andcontrol from application implementations will help tomigrate advance coordination and control policies and

mechanisms from the realm of research to practice; (2)demonstrating that our framework can be applied to prac-tical client/server protocols such as NFS and SMB; and(3) showing that our framework can specify and enforcepolicies encompassing principles that have been deemedcritical to enterprise security with acceptable overheads,even when applied to performance sensitive services suchas NFS and SMB.

II. MOTIVATING EXAMPLE

We begin by describing an example policy for control-ling accesses to a set of file servers to motivate the typeof policies that we seek to support. We will show laterhow our mechanism can enforce this policy over accessesto a set of NFS and SMB servers without requiring anychanges to the client and server applications.

To introduce our example policy, let us suppose that anenterprise has a set of registered principals (users) U , aset of roles R, and a relation M : U → R defining theroles that each principal can assume for access controlpurposes. The principals can attempt to access files storedon a set of file servers from client machines that are eitherconnected to the enterprise’s wired network or its wirelessnetwork. Initially, a wireless client is not allowed to com-municate at all with the enterprise’s networked serviceinfrastructure. The enterprise then wishes to establish thefollowing policy PE :

Authentication: To enable access from a client machine,a principal must: (1) present a certificate signed by thedistinguished certification authority ca to authenticate thatit is the owner of a public key K pub, and (2) presenta certificate signed by the private key paired with K pub

stating that it is running with uid U on the client machinewith IP address I . If the principal is using a wirelessdevice (detectable by the IP address), then the client ma-chine will be allowed to communicate with services on thewired network, including the file servers, after successfulauthentication. An authenticated registered principal gainsimmediate access under all roles that it can assume. Anunregistered principal, e.g., a guest, can also authenticatebut does not have any access rights until it gains somedelegated rights. This authentication must be renewedhourly.

Delegation: A principal p can gain delegated rights bypresenting a certificate signed by ca, specifying that someregistered principal pd has delegated certain access rightsto p under a role Rd. A registered principal pd maydelegate rights under any role Rd where Rd �= Admin and(pd, Rd) ∈ M . The delegated rights may optionally havean expiration time and be limited to a file f or directoryd, with the latter implying that the delegated rights canbe used to access all files and directories under d.

Revocation: X access denials across any subset of serverswithin an hour will lead to suspension of all delegatedrights for a particular principal. Y access denials withinan hour will lead to suspension of all access rights for aprincipal. Suspended privileges can be reactivated through

2 JOURNAL OF COMPUTERS, VOL. 1, NO. 1, APRIL 2006


PolicyDB

Principals→

RolesDB

LGILGI

Law

CertificationAuthority

SecurityManager

Protected Server

Service

Reference Monitor

PolicyDB

Protected Server

Reference Monitor

User Agent

Client App

Service

Firewall

StandardClient/ServerMessage Exchanges

StandardClient/Server

Message Exchanges

Protected Server

AC Agent

Packet Analyzer

ControlKeynote

Service

Firewall Packet Filter

User Level

Kernel

LGI

(a) (b)

Figure 1. Overview of our coordination and control framework: (a) Each server runs a software reference monitor that filters accesses to the server.While client/server interactions are unchanged (indicated by the dashed lines), the user must convince the reference monitor to allow the interactionsto take place. Servers can also be protected by dedicated firewalls for added security. (b) the reference monitor provides a unification point for theapplication of LGI and KeyNote to the coordination and control problem.

the presentation of two reactivation certificates signedby ca, specifying that reactivation permission has beenobtained from two distinct principals who can assume therole Admin.

Per-file policies: The owner of each file can establish aper-file policy1 specifying the roles that can access thatfile and their access rights.

While the above policy has been deliberately made sim-ple for ease of presentation, it still demonstrates severalimportant elements for establishing powerful yet flexibleaccess control policies. First, its support for delegationempowers users to coordinate accesses to their files moreflexibly yet securely without having to involve systemadministrators. For example, a professor can allow his TAto access course-related files by simply delegating accessrights to an appropriate directory. Further, the professorcan specify a delegation expiration time of the end of theterm to ensure that the TA does not retain access rightsforever. The professor can similarly delegate access rightsto visitors and collaborators so that gaining access forthese principals becomes just a matter of presenting a setof certificates.

Second, the stipulation that the role of Admin cannot bedelegated demonstrates the use of a global constraint toprevent individual actions that may critically impact thedependability of the system. Delegation of the Admin roleis dangerous because, among other things, Admins likelyhave write access to configuration files that can affect theperformance, reliability, and security of the system.

Third, the revocation component allows the enterpriseto establish an important restriction based on state derivedfrom a principal’s interactions with a community ofservers. Regaining revoked privileges requires the inter-vention of two administrators, which is an example of thecommon separation-of-duty principle.

Finally, note that PE places additional restrictions on

1The overload of the term policy here is somewhat confusing.Throughout our discussion, we always use the per-file prefix wheneverthere is any potential for confusion between the global policy and theper-file policies.

the ability of wireless devices to contact any networkedservice, not just the file servers, to provide additionalsecurity; this additional security may be deemed nec-essary because any visitor can attempt to connect tothe enterprise’s wireless network, making wireless clientspotentially less trustworthy than clients connected to thewired network. As shall be seen, this additional constraintwill show how our framework can coordinate dedicatedfirewalls to provide additional security where necessary.Note that this stipulation could have been a part of aseparate policy as it controls access to the entire serviceinfrastructure rather than just the file servers. Here, weinclude it in PE for simplicity.

III. OVERVIEW

Figure 1(a) gives an overview of our framework, whichconsists of a set of reference monitors (possibly includingdedicated firewalls), a set of user agents, and a set ofservices comprising the enterprise security infrastructure.In general, each node hosting software components sub-jected to enterprise-wide policies, e.g., NFS clients andservers whose interactions must obey PE , would alsohost a reference monitor. This reference monitor filters allincoming messages, passing through only those allowedby the policies in effect. Figure 1(a) shows the referencemonitors running only on the servers because this issufficient to enforce policies that only coordinate andcontrol accesses to server resources such as PE . Existingmessage passing applications such as NFS clients andservers will then interact as normal. However, this inter-action is only possible if the client’s user can “convince”the reference monitor (and any intervening dedicatedfirewalls) protecting the server to pass the client’s requeststhrough to the server.

Typically, a user can convince a reference monitorto accept his client’s access requests by obtaining andpresenting an appropriate set of credentials. The processof obtaining and presenting credentials is itself a se-quence of interactions between the user agents, referencemonitors, and security infrastructure that is subjected tocontrol by enterprise-wide policies. In our framework,



this process is coordinated using LGI, a mechanism forcontrolling message exchanges between a community ofsoftware agents according to an explicit law. Thus, theparts of a policy that are concerned with coordinating andcontrolling the gathering and presentation of credentialsmust be expressed as an LGI law. The law LE thatembodies this part of our example policy P E is discussedin detail in Section V.

The security infrastructure is typically comprised ofcomponents such as the certification authority and securitymanager shown in Figure 1(a). With respect to P E ,these components perform functions such as certificategeneration and mapping of principals to roles that theymay assume.

Each user agent is some user’s gateway to our frame-work, allowing the user to interact with the referencemonitors and security infrastructure. With respect to P E ,a user wishing to access a file server would use the useragent to authenticate himself, obtain the roles that he mayassume, and present these roles to the server’s referencemonitor to convince it to permit the access.

Each reference monitor is a combination of a soft-ware firewall and a user-level access control (AC) agent(Figure 1(b)). The firewall intercepts all packets formingprotocol-level requests that are subject to the policiesin effect and passes them to the AC agent. The ACagent uses a packet analyzer such as Ethereal [12] toreassemble these packets back into meaningful protocol-level requests. For each request, the AC agent thenextracts the information needed for access control, namelythe principal, the object to be accessed, and the accessbeing attempted.

To determine whether a request should be permitted,the AC agent would gather all information that may affectthe decision from the enterprise security infrastructure,the user agents, and possibly other reference monitors.With respect to PE , the AC agent would retrieve theroles that the requesting principal may assume from theprincipal’s user agent. Critically, since this interaction andthe interactions through which the user agent obtained theroles are controlled by LE , the AC agent can be confidentthat the user agent cannot provide false information—thereason for this confidence will become clearer once weprovide more information about LGI in Section IV-A andLE in Section V. The AC agent also contacts the policydatabase running on the protected server to retrieve anyinformation specific to the object to be accessed; e.g., theper-file access control policy.

Once it has gathered all the necessary information, theAC agent uses KeyNote, a system designed to answerthe question “does a set of credentials prove that arequest complies with an access control policy,” to decidewhether the request should be permitted. For P E , thecredentials correspond to the roles and the access controlpolicy corresponds to the per-file policy. If the requestis permitted, then the message will be forwarded to theserver. Otherwise, a request denial is returned to the client.

Information can also flow from the AC agent to the

security infrastructure and user agents. For example, theAC agent will inform the user agent when requests aredenied so that LE can enforce the revocation stipulationsof PE .

For efficiency, we assume that an AC agent can cacheinformation about principals and objects so that it doesnot need to communicate with remote services to mediateevery access request. The AC agent may also batch thereporting of request denials.

It is important to observe that the AC agent is mainlyan information conduit between LGI and KeyNote. Inparticular, policy stipulations are never embedded in thecode of the AC agent. Rather, all policy stipulations areexpressed as parts of an LGI law or as per-object KeyNotepolicies, which provides a clean separation between policyand mechanism. In essence, our approach uses LGI tocoordinate the handling of credentials between the users,the security infrastructure, and the reference monitors, anduses KeyNote to mediate specific access requests. Withrespect to PE , this maps to the use of LGI to coordinatethe management of the roles that users can gain andlose through delegation and revocation, and the use ofKeyNote to mediate specific file access requests such asopen, read, and write.

We chose LGI as the overall coordination and controlmechanism because it supports a rich domain of statefulcommunal policies in a variety of environments [13]–[16].Further, LGI’s inherently distributed nature is well-suitedto our approach since we propose to have an AC agentper node for scalability.2 We chose KeyNote because itwas specifically designed to evaluate whether an accessis authorized in a dynamic environment where principalscan delegate rights to each other. We could have usedLGI for this purpose as well. However, KeyNote targetsa more constrained problem and so its evaluation engineprovides well-defined compliance semantics and is moreefficient than LGI. In fact, as shall be seen, we do notexploit the full capability of KeyNote. Thus, an even moreconstrained evaluation engine could have led to increasedperformance.

In addition to the per-node reference monitors, differentparts of the enterprise computing environment may alsobe segregated from each other using dedicated firewalls.For example, such a firewall would be used to preventwireless devices from being able to access the enter-prise’s service infrastructure until they have successfullyauthenticated themselves according to policy P E . Thesefirewalls look similar to the per-node reference monitorsexcept that their AC agents are typically used to controlthe filtering rules of the firewalls, rather than to intercept,reconstruct, and control higher-level protocol messages.Thus, they behave like traditional firewalls, providingadditional network-level protection where deemed nec-essary; e.g., to prevent wireless devices from perform-ing denial-of-service attacks on our servers by rapidlysending illegal requests. By integrating the dedicated

2It is easy to imagine a centralized reference monitor for all theservers of an enterprise but such a design is unlikely to scale well.



firewalls into our framework, however, we allow themto be dynamically coordinated and controlled under thesame enterprise-wide policies such as PE . Users haveto convince these firewalls to pass through the client’srequests to the appropriate servers in the same manner asthey convince the per-node reference monitors to do so.

In many cases, a coordination and control policy willhave components that are specific to objects being sharedby the interacting software components as this allowsthe global policy to be augmented by the individualowners of the objects. For example, with respect to P E ,each file has an associated policy that specifies accessrights to the file by specific roles. To support the storageof these object-specific policies, we have implementeda simple policy database using the Berkeley DB [17].This is the policy database mentioned earlier, which isresponsible for servicing the AC agent’s requests for per-object policies.

Because the policy database is implemented external tothe software component (service) exporting the objects,there is a consistency issue between the policies storedin this database and the objects stored by the service. Tominimize this problem, we expect that each server wouldrun a policy database to hold the per-object policies forobjects stored by services running on that server. Then,inconsistencies should only arise if the machine crashesunexpectedly in the middle of two related writes, say thewrite of a newly created object to the service and thecorresponding per-object policy to the policy database.In this case, we would need some tool like fsck tosynchronize the policy database with the object store aftera crash.

IV. BACKGROUND AND RELATED WORK

In this section, we briefly describe LGI and KeyNoteto provide context for the discussion of our experimentalstudy in Section V. We also discuss other related work.

A. Law-Governed Interaction (LGI)

LGI is a control mechanism that governs the messageexchanges within a community of distributed agents ac-cording to an explicitly specified policy called a law.The messages exchanged under a given law L are calledL-messages, and the group of agents interacting via L-messages is called a community CL. For each agent x in acommunity CL, LGI maintains what is called the controlstate CSx of this agent. These control states, which canchange dynamically subject to law L, enable the law tomake distinctions between agents, and to be sensitive todynamic changes in their state. The semantics of controlstates for a given community is defined by its law andcan represent such things as the role of an agent in thiscommunity and the privileges it carries.

Laws. The law L governing a community CL is definedover a set of regulated events that can occur at members ofCL, mandating the effect that such events should have—this mandate is called the ruling of the law for a given

event. Regulated events include the sending and arrival ofL-messages, the coming due of an obligation (discussedbelow), and the submission of a certificate. The operationsthat comprise the rulings of the law for a regulated eventare called primitive operations. They include operationson the control state of the agent where the event occurred(called the “home agent”), operations on messages, andthe imposition of an obligation on the home agent.

Thus, a law L can regulate the exchange of messagesbetween members of CL based on the control state ofthe participants; it can mandate various side effects fora message exchange, such as modification of the controlstates of the sender and/or receiver of a message, and theemission of extra messages.

Law enforcement. The law L governing a community CLis enforced by a set of trusted agents called controllers.Controllers are logically placed between all members ofCL and are used to mediate all exchanges of L-messagesbetween them. Each member x of CL must adopt L atsome controller Tx, which maintains x’s control state andimposes L over regulated events whose home agent is x.Each L-message sent from an agent x to another agenty is then forwarded first through Tx, then through Ty ,before it is delivered to y (if allowed by L). Every L-message exchanged between a pair of agents x and y isthus mediated by their controllers Tx and Ty , so that thisenforcement is inherently decentralized although severalagents can share a single controller if desirable.

The global nature of LGI laws requires that all membersof a community CL observe the same law L. To ensurethis homogeneity, a hash H of L is appended to all L-messages sent from one controller to another. A controllerthen accepts an L-message if and only if H is identical tothe hash of its own law.

Finally, for controllers to trust one another, they mayauthenticate to each other using certificates signed by acertification authority acceptable to L.

Writing laws. LGI laws are written using either a Prolog-based or a Java-based language. The two languagessupport the exact same semantics; here, we will brieflydescribe some relevant components of the Prolog-basedlanguage.

A Prolog-based law L is a program L, which, whenpresented with a goal e representing a regulated event ata given agent x’s controller, evaluates the rule associatedwith e in the context of CSx to produce a list of primitiveoperations representing L’s ruling for e.

The regulated events most relevant to our case study inSection V include:

sent(X, M, Y): an L-message M sent by X to Y has arrivedat X’s controller.arrived(X, M, Y): an L-message M sent by X to Y hasarrived at Y’s controller.certified(X, certificate(issuer(I),subject(Y), attributes(A))): X has presenteda valid certificate issued by I. A is a list of attributes beingcertified about the subject Y.obligationDue(type): the self-imposed obligation of type



type has fired. Typically, obligations are set to occur sometimein the future to ensure that some action is carried out in a timelymanner.

In addition to the standard types of Prolog goals, thebody of a rule may contain two distinguished types ofgoals. These are sensor goals, which allow the law toaccess the control state of the home agent, and do goals,which contribute to the ruling of the law. A sensor goalhas the form t@CS, where t is any Prolog term. Itattempts to unify t with each term in the control state ofthe home agent. A do goal has the form do(p), wherep is a primitive operation. It appends the operation p tothe ruling of the law.

Commonly used primitive operations include:

+T(v): add term T to the home agent’s control state with valuev.forward(x,m,y): send message m from x’s controller toy’s controller, triggering an arrived(x,m,y) event at y’scontroller.deliver(x,m,y): deliver the message m from x (sent viax’s controller) to y.

imposeObligation(type,t): impose an obligation withthe specified type that will come due at time t.

Example. To see how the above pieces fit together,consider the simple example shown in Figure 2. Rule R1in this snippet specifies that each agent operating underlaw LID must have a name as certified by the certificateauthority ca. Then, suppose that an agent x sends anLID-message to another agent y. Recall that each suchmessage must first be routed through x’s controller T x.The arrival of the message at T x corresponds to a sentevent and so would trigger Rule R2. The ruling ofRule R2 is to forward the message prepended with x’sname to y at T y. The addition of x’s name to the messageensures that spoofing is impossible. When the messagearrives at T y , it would trigger Rule R3, which leads tothe delivery of the message to y.

B. KeyNote

KeyNote is a trust management system designed toanswer the question: does a set of credentials C provethat a request r complies with a local security policyP ? Specifically, KeyNote implements a general-purposeevaluation engine that can be invoked by an applicationeach time it needs to answer the above question. Foreach invocation, the application passes to KeyNote a listof credentials, a set of policies, the requester’s publickeys, and a set of environment attributes. The result ofeach evaluation is an application-defined string such as“authorized” or “denied.”

Policies and credentials are specified using KeyNote’sassertion language, where each assertion is essentially adelegation of some rights. The only difference betweenpolicies and credentials is that each credential must becryptographically signed whereas a policy is trusted byKeyNote and so is not signed; this means that KeyNote

R1) adopted(Any, cert([certificate(issuer(ca),subject(Self),attributes([name(N)]))]))

:- do(+name(N)).

R2) sent(X, M, Y) :- name(N)@CS, do(forward(X,[from(N)|M], Y)).

R3) arrived(X, M, Y) :- do(deliver).

Figure 2. Snippet of an example law LID .

must cryptographically validate credentials but not poli-cies during an evaluation. Attributes are also trusted andso are not validated during the evaluation.

Each KeyNote assertion takes the following form:

Authorizer: “POLICY”Licensees: “<public key>”Conditions: (file == “f” && operation == “read”)

→ “authorized”;

where the Authorizer field identifies the principal thatis delegating some rights, the Licensees field specifiesa set of receiving principals, and the Conditions fieldspecifies the rights to be delegated along with a set ofconditions on the environment attributes that must betrue for the delegation to hold. In the example above,the string POLICY indicates that this is a root assertionrepresenting an “intrinsic” (as opposed to delegated) setof rights; the Licensees field specifies the public key rep-resenting some receiving principal p; and the Conditionsfield specifies that p should be given “read” access tofile f . In general, the set of licensees can be specifiedusing expressions formed from conjunction, disjunction,and threshold operations. Conditions may include stringcomparisons, numerical operations and comparisons, andpattern-matching operations.

Each time it is invoked, KeyNote performs a depth-firstsearch through the given credentials and policies to findan assertion graph from one or more root assertions toan assertion that authorizes the request. Each assertionin this chain represents a delegation of rights and thuscan only refine the authorizations conferred on it by theprevious assertions in the graph. If no such chain can befound, then the answer to the compliance question is no,which is mapped to an application-defined string such as“denied.”

C. Other Related Work

A number of research and industry efforts have ex-plored the use of a centralized reference monitor toimpose global access control policies [5], [18], [19].In contrast, our system uses a distributed network ofreference monitors, one per server, and uses LGI tocoordinate between them and other security services. Theinherently distributed nature of our mechanism providesthree important advantages. First, the access control eval-uation can be done at the server itself, avoiding theoverhead of additional network communication. Second,our framework is more scalable and does not have asingle point of failure. Tivoli is one centralized systemthat has addressed the second issue through the replication



of the reference monitor [5]. However, such replicationintroduces the difficulty of maintaining consistent statein the presence of dynamic policies. In fact, Tivoli’saccess control model is mostly limited to static policies;while Karjoth showed that Tivoli can support the ChineseWall policy, this involved extending Tivoli (through anextension API) with customized code. It was unclearhow this extension interacted with the replication. Finally,while not addressed in this work, our framework can beused to enforce hierarchies of policies across coalitionsof enterprises, addressing a problem that is rapidly risingin importance.

Our reliance on the ubiquity of software firewalls issimilar to Bellovin’s work on distributed firewalls [20].However, Bellovin’s work was concerned with dynami-cally adjusting firewall policies of individual machines asthe environment around them changes.

One effort that is particularly related to our experimen-tal study of access control for file systems is Miltchevet al.’s Distributed Credential File System (DisCFS) [21].This work explores the use of KeyNote and IPSec to ex-tend NFS’s access control model to the general credential-based model of KeyNote. This work is related to ourin that it seeks to introduce a richer access controlmodel, including dynamic delegation, to file systems.It’s different than our work, however, in that it requiredchanges to the file system client and server; indeed, itled to the new DisCFS file system. In general, a keycontribution of our work is that we seek to provide apractical gateway for applying trust management systemsand advance policies to standard client-server protocolswithout requiring changing the protocols or applications.Further, our use of LGI allows us to support communalpolicies that KeyNote was not designed for.

V. CASE STUDY

In this section, we first show how our framework canbe used to explicitly specify and uniformly enforce policyPE across a set of heterogeneous NFS and SMB servers.We then evaluate the performance of our implementation.Finally, we draw on our implementation experience todiscuss characteristics that would make protocols moreamenable to coordination and control mechanisms thatdepend on the interception of messages such as ours.

A. Implementation

Our implementation includes a security manager, a useragent, an AC agent, a policy database, and a law LE .The security manager is an LGI-aware application thatmaintains a database of registered users and the rolesthat they can assume using the Berkeley DB. The useragent is a simple LGI-aware application that allows theuser to present certificates for authentication and gainingdelegated rights. The user agent is simple enough thatit can be implemented as a Java Applet runnable fromany Java-enabled browser. The AC agent is an LGI-awareapplication that uses a combination of iptables, Ethereal,

Preamble: authority(ca, keyHash(Kpubca )).

alias(sm, ”[email protected]”). initialCS([]).

ca is the distinguished certification authority trusted by this law.sm is the distinguished security manager.

R1) certified(UA, certificate(issuer(ca),subject(UA),attributes(name(NAME))))

:- do(addAuthority(NAME,keyHash(SubjectHash))),do(add(meAsCA(NAME))).

The user agent has presented a valid certificate doubly signed byca and itself specifying that its name is NAME. Save the user’spublic key as an authorizer in order to accept future certificatessigned by the user. Also save the certified name NAME.

R2) certified(UA, certificate(issuer(N),subject(UA),attributes(ip(IP),uid(UID))))

:- meAsCA(N)@CS, do(forward(Self,attributes(ip(IP), id(UID), name(N)),sm)).

The user agent is informing the security manager that its user isrunning with user id UID on the client machine with address IP.

R3) arrived(UA, attributes(ip(IP), id(UID),name(N)), SM) :- do(add(user(ip(IP),id(UID), lgiName(UA)))), do(deliver).

When a message from UA containing a (IP, UID, N) tuplearrives at the security manager’s controller, save the tuple (IP,UID, UA) to the security manager’s control state and deliver themessage.

R4) sent(SM, roles(R), UA):- do(forward(SM, roles(R), UA)).

The security manager is sending back the roles that a user mayassume to the user’s user agent.

Figure 3. Part of the enterprise law LE .

and KeyNote to enforce access control on specific re-quests. The policy database is a simple wrapper aroundthe Berkeley DB that holds the per-file policies.

The interactions between the user agents (one per user),security manager, and AC agents (one per server + oneon a dedicated firewall that separates the wired networkinfrastructure from the wireless network) are coordinatedand controlled by LE . We show a small snippet of LE

in Figure 3 just to give the reader a feel for what the lawlooks like. The entire law, comprised of approximately 40rules, can be found at http://p2p.cs.rutgers.edu. We alsoshow one critical message exchange sequence coordinatedby LE in Figure 4.

In the remainder of the section, we first describehow policy PE is expressed and enforced by the abovecomponents. Then, we describe how the AC agent de-rives the necessary information (principal, object, andaccess request) from protocol messages and its cachingand buffering actions. Finally, we discuss implementationdetails specific to processing NFS and SMB protocolmessages.

Authentication. To access a server protected by our sys-tem from some client machine, a user must authenticatehimself to the system by running the user agent. Onstartup, the user agent first connects to an LGI controllerand adopts LE . Then, it presents two certificates: (1) acertificate signed by the distinguished certificate authorityca acceptable to LE (Preamble in Figure 3) specifying



that the user owns a particular user name N and publickey Kpub; and (2) a certificate signed by the privatekey paired with Kpub specifying the user’s UID and theclient machine’s IP address. The presentation of the 1stcertificate, assuming that the certificate is valid, leads tothe addition of N and K pub to the user agent’s controlstate (Rule R1). The presentation of the 2nd certificateleads to the forwarding of the tuple (IP, UID, N) to thesecurity manager (Rule R2).

When the above message arrives at the security man-ager’s controller, the pair (IP, UID) together with theuser agent’s LGI name will be inserted into the securitymanager’s control state (Rule R3). The user agent’sLGI name is saved so that future queries from the ACagents can be forwarded to the user agent (see SubsectionEnforcement below). An obligation will also be set todiscard this entry if a keep-alive message is not receivedwithin time Tsmc. Finally, a query message containing thename N will be generated and forwarded to the securitymanager.

If the security manager detects that N is authenticatingfrom a wireless client (determined from the client’s IP ad-dress), it informs the AC agent running on the interveningdedicated firewall to allow the client to communicate withthe enterprise’s networked service infrastructure. (The ruleimplementing this action is not shown here.)

In addition, if the security manager finds N in itsdatabase, it will reply with the list of roles that the usercan assume (Rule R4). When this reply arrives at theuser agent’s controller, the roles will be inserted into theuser agent’s control state (rule not shown). The reply isthen forwarded to the user agent to inform it that theauthentication process has been completed and the rolesthat its user may assume.

While the user agent is connected to its controller andoperating under LE , an obligation is set to periodicallysend a keep-alive message to the security manager so thatthe user’s authentication information will not be discardedfrom the security manager’s control state.

Delegation. Registered principals can delegate their ac-cess rights to others by providing them with certificatessigned by ca specifying the delegating principal Pd,the receiving principal Pr, the delegated role Rd, and,optionally, the delegated rights, a file or directory, andan expiration time. A receiving principal can then invokedelegated rights by presenting one or more delegationcertificates through the user agent. If the delegated roleis Admin, the delegation will be unconditionally refused.Otherwise, a message will be forwarded to the securitymanager to verify that the delegating principal may as-sume the delegated role. A positive reply from the securitymanager will lead to the delegated rights being added tothe control state of the user agent. If the control state ofthe user agent contains a non-empty list of AC agents (seeSubsection Enforcement below), then the newly acquiredrights will be forwarded to these AC agents. Finally, if thecertificate had an expiration time, an obligation is set upto discard the entry at that time.

For the remainder of the discussion, we refer to theroles pre-assigned to a user as his intrinsic roles androles that the user has gained through delegation as hisdelegated roles.

Per-File Policies. Each file has an owner and an owner-specified access control policy describing the roles thatcan access the file and the corresponding access rights. Arole may be an arbitrary string, e.g., “Admin,” or a publickey, in which case only the owner of the correspondingprivate key can assume that role. The access controlpolicy is expressed as a Keynote policy. Currently, theset of possible access rights include {read, write, search}and each access evaluation can return one of {granted,denied}. The search right is equivalent to Unix’s accessright x for directories.

When a file is created, the AC agent assigns it a defaultaccess control policy specified by the owner. The ownercan access and modify this policy as desired using a setof simple scripts that we have developed.

Enforcement. For each intercepted access, e.g., read orwrite, if the AC agent currently has no information aboutthe requesting principal, it would send a message to thesecurity manager (M1 in Figure 4). This message is routedthrough the AC agent’s controller, triggering the sentevent E1, which simply forwards the message (M2) tothe security manager. At the security manager’s controller,this message will be rerouted to the principal’s user agentusing the user agent’s LGI name that was saved earlier(E2 and M3). At the user agent’s controller, this messagewill cause this particular AC agent’s LGI name to beinserted into the user agent’s control state (E3). A messagecontaining all of the principal’s roles is also sent to the ACagent (M4). Expiration times and file/directory restrictionsfor delegated roles are also included. At the AC agent’scontroller, the message is delivered to the AC agent (M5),which can now use the roles to mediate the interceptedrequest.

If the object being accessed is the file /a/f , then the ACagent also needs to access the policy database to obtainthe per-file policies associated with /, a, and f . Finally,the AC agent would invoke KeyNote three times, twiceto determine whether the principal has search right for /and /a and once to determine whether the principal hasthe necessary access right to /a/f .

For each evaluation, intrinsic roles are passed toKeyNote as attributes while delegated roles are passedas policy assertions as follows. Suppose that a principalidentified by key Kpub can assume a delegated role ofRd and is attempting to access file f . In this case, thefollowing assertion will be generated:

Authorizer: “Rd”Licensees: “< Kpub >”Conditions: (operation == “read” || operation == “write”

|| operation == “search”) →“granted”;

For the above rule to have an effect, however, somerule granting access rights to Rd would have to exist inf ’s policy. For example, suppose f ’s policy includes thefollowing assertion:



NFS or SMBClient

PacketFilter

Request(IP, UID,Op, Name)

ACAgent

Controller

M1: QueryRoles(IP, UID)

E1: Sent

Controller

M2: QueryRoles(IP, UID)

E2: ArrivedController

M3: QueryRoles(IP, UID,AC Agent’s LGI Name)

(IP, UID, UA’s LGI Name)

E3: Arrived

{Roles},{AC Agents’ LGI names}

M4: Roles({Roles})

E4: Arrived

M5: Roles({Roles})

SMUA

MMessage E Regulated LGI Event … LGI Control StateLegend:

Figure 4. Message exchange sequence for the AC agent to obtain theroles that the requesting principal may assume.

Authorizer: “POLICY”Licensees: “Rd”Conditions: (operation == “read”) → “granted”;

Then, the principal would gain read access to f throughthe authorization chain of POLICY → Rd → Kpub.

If the results of all KeyNote evaluations are granted,then the intercepted request will be forwarded to theserver. If the result is denied, then the access is notauthorized. In this case, either an error is generated andsent back to the client or the request is modified in sucha way that is guaranteed to force the server to deny therequest.

A count of denied accesses is maintained for eachprincipal. Each time this count reaches a predeterminedlevel, the AC agent sends a message to the principal’suser agent. When this message arrives at the user agent’scontroller, the count will be added to an overall countmaintained in the user agent’s control state. An obligationwill periodically clear this count. According to P E , if thiscount ever exceeds a certain level, a suspension tag willbe added to the user agent’s control state. This tag willprevent all further accesses. Regaining blocked privilegesis done by presenting two reactivation certificates issuedby distinct principals under role Admin.

Caching inside the AC agent. The AC agent caches threetypes of information: (1) Per-file access control policiesare cached for an adjustable period Tcp. These policiesare always discarded after Tcp regardless of client accesspatterns to ensure that the cached information does notbecome stale because of updates by the file’s owner. (2)Principals’ credentials are cached for an adjustable periodTcc. This period is extended by Tcc every time the ACagent receives a “keep alive” message from the principal’suser agent. And (3) KeyNote evaluation results are cached

TABLE I.CONTROLLED MESSAGE TYPES

Protocol Regulated MessagesNFS MOUNTPROC MNT, MOUNTPROC UMNT,

MOUNTPROC UMNTALL, LOOKUP, SETATR,READLINK, READ, WRITE, CREATE, REMOVE,RENAME, LINK, SYMLINK, MKDIR, RMDIR,READDIR

SMB SESSION SETUP, TREE CONNECT, OPEN, CLOSE,TREE DISCONNECT, CREATE, CREATE NEW,CREATE TEMPORARY, CREATE DIRECTORY,DELETE DIRECTORY, DELETE, MOVE, RENAME

using a tuple of (access type, IP, UID, object’s pathname)as the key. These results are invalidated when the prin-cipal’s credentials change and/or the object’s policy isevicted from the policy cache.

Implementation details for NFS. Our system does notintercept all messages to minimize control overhead; wewrote some simple iptables extensions to intercept only asubset of NFS message types and pass them to the user-level AC agent. Table I lists the message types that wedo intercept and control. These map to important accessessuch as read, write, open, create, delete, etc. We do notcontrol purely informational requests such as an inquiryfor the attributes of a file. In a highly secure environment,this might present a disclosure concern, which wouldnecessitate the interception and control of all messagetypes.

Recall that for each access, we must extract the prin-cipal, the object, and the access type. The principal andaccess type are easily extracted from NFS client requests.Extracting the name of the object being accessed is moredifficult, requiring the mapping of an NFS handle to apathname. Fortunately, Ethereal already implements thelogic necessary to extract such mappings from requestssuch as LOOKUP and the corresponding replies andmaintains them in a hash table. Evicting entries from thistable can be difficult, however, because NFS versions 2and 3 use persistent file handles. Any eviction may causeour system to not have the necessary mapping to evaluatea future request. Currently, we evict mappings that havenot been used for a threshold amount of time despite thisproblem. If the system ever receives a request containinga handle that cannot be mapped, it returns a stale handleerror, which becomes visible to the user. NFS version 4allows the server to limit the use of a handle to somefinite period, which solves this problem.

If an evaluation leads to a denial of an access, the ACagent will send an NFSERR ACCES reply back to theclient.

In our system, the NFS servers are set up withAUTH UNIX authentication. All directories to be ex-ported are set up as world-writable and exported withrw and async options. All users authenticated by thesecurity manager can mount an exported directory. Thelocal permissions of files and directories are set to worldread, write, and access.

Implementation details for SMB. Similar to NFS, wedo not intercept all SMB messages; Table I shows the



TABLE II.LATENCIES OF VARIOUS MICRO OPERATIONS

Operation TimeKeynote eval. of simple root policy 23 usKeynote eval. of root policy + 1 delegation 41 usKeynote eval. of root policy + 10 delegations 172 usAC agent obtains a per-file policy from policy DB

containing 50,000 entries 8.0 uscontaining 500,000 entries 20.8 us

Authentication with the security manager under LE 509 msAC agent obtains roles from user agent 61 ms

message types that are intercepted. Interestingly, note thatwe do not need to intercept read/write requests. This isbecause the necessary access control is already performedat the open; for example, the server will itself refuse awrite request on a file that was opened only for read.

SMB servers are set up to use user-level authentication.All shares are set up in such a way that only one particularuser can access them. This user is private and only knownto the AC agent. When an authenticated user tries toaccess an SMB share, before the request reaches theserver, the user name and password will be replaced withthe private user by the AC agent.

Similar to NFS, the AC agent maintains a map betweenfile ids and file names. An entry will be evicted when theAC agent sees a close message for a particular file id.Unlike NFS, the AC agent also associates a connectionwith each specific principal and its roles. SMB servers arealso set up to send keepalive packets every 1 minute. Aconnection will be considered as dead by the AC agent ifit doesn’t receive any packets in 3 minutes. The AC agentwill silently reclaim all resources of a dead connection.

To deny an access, the AC agent will modify the requestto ensure that the request will be refused by the SMBserver based on its local access control policy. Then, whenthe server receive the request, it will reply with an accesscontrol error. For example, if the request is to open the filewith read/write flags while the policy states that the useronly has read permission, the write flag will be removedfrom the request. For users who tries to access a file whichhe has no permission, the file name will be changed to alocal special file which is owned by a private user and isset up with permissions disabled.

B. Performance

We now quantify the performance impact of our ap-proach. We first present micro-benchmark measurementsfor a client to access an NFS and SMB server when op-erating under policy PE . Then we present measurementsusing the modified Andrew benchmark [22] to evaluatethe impact on normal usage of the protected file systems.

Our experimental setup was as follows. We had 1 LGIcontroller running on a 1.6GHz P4 PC with 512MB ofmemory. We had 1 NFS server, 1 SMB server, 1 client,and 1 security manager, each of which was running ona separate 2.8GHz P4 PC with 1GB of memory. Allnodes ran Linux v2.6.9. The security manager used theBerkeley DB version 4.2.52 to hold the public keys and

TABLE III.PER-OPERATION LATENCIES

Base RM-ACFS Op. Time (us) Time (us) % Deg.

NFS create 420 677 61.2write 170 257 51.2read 151 236 56.3

SMB create 1,042 1,246 19.6write 212 213 0.5read 175 176 0.6

roles of registered principals. We populated this databasewith 500 entries to represent a medium-sized enterpriseunit. Each file server also ran a policy database and ourreference monitor, where the AC agent used iptables 1.2.9,the Ethereal packet analyzer version 0.10, and KeyNoteversion 2.3. The client and servers are configured to useIPsec Authenticated Header in tunnel mode to prevent IPspoofing, ensuring the integrity of identifying a user byhis (IP, UID) pair.

Micro-benchmarks. Table II gives the times to performKeynote evaluations, to access a Berkeley DB, and tocomplete various LGI-mediated interactions. Of these,the costs of KeyNote evaluations are probably the mostsignificant as they may be incurred frequently. Theseresults show that the base cost for a KeyNote evaluationis fairly expensive but probably acceptable, particularlysince we cache the results of these evaluations. Althoughour current policy only allows a single level of delegation,we also present the times for KeyNote evaluations whengiven longer delegation chains. These results show thatvery long delegation chains can lead to large performanceoverheads.

The cost of obtaining a per-file policy from the serveris purely the cost of accessing the Berkeley DB database.This cost seems quite reasonable, particularly since wealso cache these policies for 30 seconds. Finally, we showthe authentication time and the time for the AC agent toobtain a user’s roles for completeness; these times are notof real concern because they are typically incurred onlywhen the user is initiating access.

Table III compares the worst-case per-operation laten-cies for create, read, and write operations performed underour framework (RM-AC) with the base case of no globalaccess control. Recall that when a file is created, it isgiven a default access control policy. Thus, the time forcreate includes the time for creating a default policyand writing it to the policy database. The times for readand write do not include accesses to the policy databasesince the corresponding per-file policy has been cached(via the create).

For SMB, there is almost no overhead for read andwrite because our framework only has to control createsand opens; the server will itself refuse a write requeston a file that was open only for read (and vice versa).The overhead for create is also not too high at 19.6%.For NFS, the overheads are much more significant. It isparticularly high for create because each create involves



0

5000

10000

15000

20000

1 2 3 4 5

Number of Clients

Nu

mb

er o

f o

ps/

s

Base 1B writes

RM-AC 1B writesBase 4K writesRM-AC 4K writes

Figure 5. Write throughput.

several messages that must be intercepted for both controland for mapping handles to file names. Overheads for thefirst read and write to a file are significant because readsand writes must be intercepted and controlled. Subsequentaccesses, however, should be more efficient because theAC agent caches the results of KeyNote evaluations. Also,when we consider the common case of reading/writinglarger amounts of data, the overheads become much lower.For example, the latency only degrades by 23% and 10%when writing 4KB and 8KB of data, respectively.

Finally, Figure 5 shows the impact of our frameworkon an NFS server’s write throughput.3 Observe that whenwriting 1B, the overhead can be quite significant, with ourapproach saturating much before the base case. However,when writing 4KB, throughput degradation is negligible.

Modified Andrew Benchmark. Next we look at the im-pact of our approach at the macro-level using the modifiedAndrew benchmark. This benchmark has five phases asfollows: (1) mkdir: creates a tree of directories, (2) copy:copies a 14,488KB collection of C source files into thedirectory tree created in phase 1, (3) stat: traverses the newtree and examines the status of each file and directory,(4) grep: reads every file in the new tree, searching fora string, and (5) compile: compiles and links the files.Table IV shows the results for both NFS and SMB. First,observe that the overhead of our approach is quite lowwhen file system activities are interspersed with non-trivial computation (and each KeyNote evaluation is likelyamortized across a sequence of read/write operationsbecause of caching effects): 1–3% for the compile phaseand 1–14% for the grep phase. (The overhead for thegrep phase running over NFS is especially low becausethe NFS client is still caching much of the content fromthe copy phase.) On the other hand, the overheads areconsistent with our micro-benchmark measurements forthe three phases that involve just file system activities,mkdir, copy, and stat.

C. Discussion

Our goal is to be able to enforce enterprise-widepolicies on client-server interactions without requiring

3In this experiment, the clients ran on slower machines, hence thethroughput for 1 client is less than what one would compute fromTable III.

TABLE IV.MODIFIED ANDREW BENCHMARK

Base RM-ACFS Phase Time (ms) Time (ms) % Deg.

NFS mkdir 49 85 74.9copy 2,051 2,558 24.7stat 512 688 34.3grep 1,084 1,090 0.6compile 21,282 21,837 2.6

SMB mkdir 88 110 24.1copy 3,232 3,587 11.0stat 239 244 2.0grep 3,805 4,339 14.0compile 21,707 21,859 0.7

changing or extending the application protocols. How-ever, our implementation exposed several characteristicsof protocols that can either ease our task or make itmuch more challenging. In particular, controlling NFSand SMB, which represent significantly different designpoints proved insightful.

First, NFS’s use of a connection-less protocol (UDP)made it much easier for us to generate error messageswhen necessary. Thus, access denials were easy to im-plement. SMB’s use of TCP made it difficult to insertmessages directly into the connection; thus, we had tomanipulate the access requests very carefully to imple-ment denials. In general, protocol features for allowingexternal input on whether a request should be acceptedor denied would significantly ease the implementation ofan external access control mechanism such as ours.

On the other hand, the stateless nature of NFS, partic-ularly with respect to the fact that there are no open andclose operations led to several difficulties. First, we hadto control each and every read and write access, whichleads to greater overhead. Second, evicting mappings fromfile handle to file names was difficult. Thus, protocols thatbound a stream of accesses to an object with distinguishedrequests (e.g., open and close) where access control canbe limited to these distinguished requests should lead tobetter efficiency.

Finally, in both cases, we had to maintain a mappingof external object names (file names) to internal handles.We suspect that this is a representative problem for mostservers, which may prove to be the trickiest challengefor applying our approach to an arbitrary protocol. Thus,protocols should limit the lifetimes of internal handlesgiven out to clients, perhaps by using renewable leasesfor such handles. Also, it should be easy to map internalhandles to external object names. (Clearly, this should betrue for the principal’s identity as well since we needthe principal, operation, and the object being accessed toperform access control.)

In summary, our approach uses standardized messageexchange protocols as the intersection points betweenour access control mechanism and applications. Thus,protocol characteristics can strongly affect the applica-bility of our approach. The above are some of the waysthat protocol designers can help to make protocols more



amenable to our approach.Orthogonal to the above protocol-related issues is the

issue of message interception in the presence of encryptedcommunication. Application-level encryption can presentan unsurmountable obstacle to our framework (withoutrequiring changes to the application). Encryption is not aproblem, however, when the application relies on system-level encryption mechanisms such as IPSec and portredirection through ssh tunnels since we can intercept themessages after they have been decrypted but before theyare forwarded to the application.

VI. CONCLUSION

In this paper, we have introduced a novel frameworkfor enforcing enterprise-wide coordination and controlpolicies over conglomerates of software components thatinteract using standardized message exchange protocols.Our framework can express and enforce sophisticatedpolicies without requiring any changes to existing appli-cations. Our approach also allows new applications to bedeveloped that are neutral with respect to specific coor-dination and control frameworks, effectively decouplingenterprise-wide coordination and control from applicationimplementation.

Our approach centers around the use of firewall-basedreference monitors, one per server, as transparent “hooks”for intercepting and controlling message exchanges. Wethen combine these hooks with LGI and KeyNote, twoexisting complimentary systems, to provide a powerfuland scalable coordination and control framework.

We demonstrate the feasibility and power of ourframework by providing a concrete example, the unifiedenforcement of an enterprise-wide policy across NFSand SMB file servers. We show how our frameworkcan be used to support an enterprise-wide policy thatincludes RBAC, delegation, revocation, and separation-of-duty. Measurements of our implementation show that ourmechanism can incur non-trivial but acceptable overheads.We thus conclude that our approach can be used as apractical migration path for moving advance coordinationand control policies and mechanisms from the realm ofresearch to practice.

ACKNOWLEDGMENT

We thank Naftaly Minsky for numerous discussionsconcerning this work, Xuhui Ao and Constantine Serbanfor their assistance with LGI, and the reviewers for theirdetailed comments.

REFERENCES

[1] J. O. Kephart and D. M. Chess, “The Vision of AutonomicComputing,” IEEE Computer, vol. 36, no. 1, Jan. 2003.

[2] D. A. Patterson, A. Brown, P. Broadwell, G. Candea,M. Chen, J. Cutler, P. Enriquez, A. Fox, E. Kiciman,M. Merzbacher, D. Oppenheimer, N. Sastry, W. Tetzlaff,J. Traupman, and N. Treuhaft, “Recovery Oriented Com-puting (ROC): Motivation, Definition, Techniques, andCase Studies,” University of California, Berkeley, Tech-nical Report UCB//CSD-02-1175, Mar. 2002.

[3] M. Satyanarayanan, “Digest of Proceedings,” in Proceed-ings of the 7th Workshop on Hot Topics in OperatingSystem, Mar. 1999.

[4] M. Blaze, J. Feigenbaum, and A. D. Keromytis, SecureInternet Programming, Security Issues for Mobile and Dis-tributed Objects, ser. Lecture Notes in Computer Science.Springer-Verlag, 1999, vol. 1603, ch. The Role of TrustManagement in Distributed Systems Security.

[5] G. Karjoth, “The Authorization Service of Tivoli PolicyDirector,” in Proceedings of the 17th Computer SecurityApplications Conference (ACSAC), Dec. 2001.

[6] N. Minsky and V. Ungureanu, “Law-Governed Interaction:a Coordination and Control Mechanism for HeterogeneousDistributed Systems,” ACM Transactions on Software En-gineering and Methodology (TOSEM), vol. 9, no. 3, July2000.

[7] T. Ryutov and C. Neuman, “Representation and Evaluationof Security Policies for Distributed System Services,” inProceedings of the DARPA Information Servability Con-ference Exposition, Jan. 2000.

[8] D. Brewer and M. Nash, “The Chinese Wall SecurityPolicy,” in Proceedings of the IEEE Symposium in Securityand Privacy, May 1989.

[9] N. Minsky and D. Rozenshtein, “Controllable Delegation:An Exercise in Law-Governed Systems,” in Proceedings ofthe 4th ACM Conference on Object-Oriented ProgrammingSystems, Languages and Applications (OOPSLA), Oct.1989.

[10] L. Snyder, “Theft and Conspiracy in the Take-GrantModel,” Yale University, Tech. Rep. 147, 1978.

[11] T. Ryutov and C. Neuman, “The Specification and En-forcement of Advanced Security Policies,” in Proceedingsof International Workshop on Policies for DistributedSystems and Networks (POLICY), June 2002.

[12] “Ethereal,” http://www.ethereal.com/.[13] X. Ao and N. Minsky, “On the Role of Roles: from Role-

Based to Role-Sensitive Access Control,” in Proceedingsof the 9th ACM Symposium on Access Control Models andTechnologies, June 2004.

[14] X. Ao, N. Minsky, and V. Ungureanu, “Formal Treatmentof Certificate Revocation Under Communal Access Con-trol,” in Proceedings of the IEEE Symposium on Securityand Privacy, May 2001.

[15] T. Murata and N. Minsky, “Regulating Work in Digital En-terprises: A Flexible Managerial Framework,” in Proceed-ings of the Cooperative Information Systems Conference(CoopIS), Oct. 2002.

[16] ——, “On Shouting “Fire!”: Regulating Decoupled Com-munication in Distributed Systems,” in Proceedings of theInternational Middleware Conference, June 2003.

[17] “Sleepycat Software. Berkeley DB,”http://www.sleepycat.com.

[18] V. Varadharajan, C. Crall, and J. Pato, “Authorization inEnterprise-wide Distributed System: A Practical Designand Implementation,” in Proceedings of the 14th ComputerSecurity Applications Conference (ACSAC), Dec. 1998.

[19] T. Woo and S. Lam, “A Framework for Distributed Au-thorization,” in Proceedings of the 1st ACM Conference onComputer and Communications Security, Nov. 1993.

[20] S. M. Bellovin, “Distributed Firewall,” ;login: SpecialIssue on Security, Nov. 1999.

[21] S. Miltchev, V. Prevelakis, S. Ioannidis, J. Ioannidis, A. D.Keromytis, and J. M. Smith, “Secure and Flexible GlobalFile Sharing,” in Proceedings of the USENIX AnnualTechnical Conference, Freenix Track, June 2003.

[22] Y. Saito, C. Karamanolis, M. Karlsson, and M. Ma-halingam, “Taming Aggressive Replication in the PangaeaWide-Area File System,” in Proceedings of the 5th Sym-posium on Operating System Design and Implementation,Dec. 2002.



Tuan Phan is currently a Ph.D. candidate at Rutgers, The StateUniversity of New Jersey, USA. He received his MS and BSdegrees in network and computer science from the VietnamNational University of HoChiMinh City, Vietnam, in 2002 and1998, respectively.

He was a lecturer at the Vietnam National University ofHoChiMinh City, Vietnam, 1999-2002. His research interestsinclude security, Internet services and distributed systems.

Zhijun He received his MS degree in computer science fromRutgers, the State University of New Jersey, USA, in 2004.

He is currently a Software Engineer at Ask.com, Piscataway,NJ. Before joining Ask.com, he was a consultant for ThomsonCorp. His research interests include security and autonomiccomputing.

Thu D. Nguyen was born in Saigon, Vietnam. He receivedhis PhD degree in computer science from the University ofWashington in 1999, his MS degree in electrical engineeringand computer science from the Massachusetts Institute of Tech-nology in 1988, and his BS degree in electrical engineering andcomputer science from the University of California, Berkeley in1986.

He is currently an Assistant Professor of Computer Scienceat Rutgers, the State University of New Jersey, USA. He wasa Member of Technical Staff at AT&T Bell Laboratories from1986 to 1991. His current research interests include the perfor-mance, availability, and security of distributed systems, rangingfrom cluster-based Internet services to peer-to-peer systems.

Prof. Nguyen is a member of the IEEE Computer Societyand the ACM. He is a recipient of the US National ScienceFoundation CAREER award.



Documents

Using Firewalls to Enforce Enterprise-wide Policies - ResearchGate