WO2001048634A2

WO2001048634A2 - Virtual resource attribute directory

Info

Publication number: WO2001048634A2
Application number: PCT/CA2000/001568
Authority: WO
Inventors: Eugen Bacic; Tony White
Original assignee: Texar Software Corp.
Priority date: 1999-12-27
Filing date: 2000-12-21
Publication date: 2001-07-05
Also published as: AU2336901A; WO2001048634A3; CA2395494A1

Abstract

Computer data is stored in a real file system. Attributes pertaining to the files in the real file system are stored at corresponding locations in the virtual file system, thereby decoupling the storage of attribute information from the data. Typically the file attributes relate to security information.

Description

Virtual Resource Attribute Directory

Field of the Invention

This invention relates to computer security, and in particular a method of controlling access to files in a computer system. Background of the Invention

Computer operating systems, such as Unix, MS DOS and Windows, typically organize files in a tree structure. These files are given attributes, which are stored along with the files in the directory structure. Such attributes can include security controls determining who is permitted to access the files. The tight binding of security attributes with the information that they secure found in traditional operating systems leads to a restrictive and inflexible security policy implementation that varies from operating system to operating system. As a result, especially in networks running multiple operating systems, this inflexibility makes it difficult to permit central administration of security policy within a system. Summary of the Invention

According to the present invention there is provided a method of controlling access to computer data, comprising the steps of: creating a real file system in a computer for storing said data; creating a virtual file system that mirrors said real file system but lacks the stored data; and storing attributes pertaining to the files in said file system at corresponding locations in said virtual file system.

Typically the attributes contain security information determining who is permitted access to the files. The virtual file system is known as a virtual resource attribute directory. The essence of the invention is that it abstracts security away from the simple, fixed attributes that are available within particular operating systems.. The invention ensures that enterprise security policies are defined outside of the operating system, are administered centrally and applied to a single type of structure, the entity. This uniformity ensures policy coherence within an enterprise. In another aspect the invention provides a virtual resource attribute directory comprising a shadow directory structure mirroring a real file structure and storing attributes of files in said real file structure without the associated data.

The Virtual Resource Attribute Directory (VRAD) defines the structure of the virtualized elements of the information being protected. The principal function of the VRAD is to mediate access to information elements. The VRAD provides a mechanism to ensure that the security attributes required for proper functioning of a security system exist and are accessible. The VRAD is unique for a variety of reasons:

• Non-intrusive to the virtualized system

• Full mapping of extant security controls to security attributes

Additional security attributes per entity protected for fully realizable security policies

• Portable, non-system dependent

Extensible and user configurable

• Easily manipulatable

The Virtual Resource Attribute Directory manages the security of information elements stored within it. The VRAD is thus a shadow of the real file system. For example, if the file system is a UNIX file system, then the VRAD would be a virtualization of the UNIX file system. At no point are the actual files modified in any way. No information is stored on the virtualized system other than that associated with the operational agents. There is a clear separation of security and information in a VRAD-managed system. The importance of the security features built into the operating system is significantly diminished.

Brief Description of the Drawings

The invention will now be described in more detail, by way of example only, with reference to the accompanying drawings, in which:-

Figure 1 is an example showing linked security servers; and

Figure 2 is an example showing cross linking of VRAD file systems. Detailed Description of the Invention

Referring to Figure 1 , it will be seen that the Virtual Resource Attribute Directory (VRAD) 10, typically stored on a hard disk, resembles a rooted tree structure 12. This tree structure 12 represents the parent-child relationships that are found in the directory structures of all important file systems. The root 14 of a VRAD can be a security server also known as a generic policy engine, which controls all aspects of security on a network. All elements in the VRAD are represented by entities and proxy entities.

All the VRADs 10 are connected by a super-tree which has at its terminals the VRADs of the virtualized systems as shown in Figure 2. The various VRADs need not be from the same type of operating system. The VRAD is utilized to create a homogenous representation of all the information that resides within a security controlled realm. This includes unified user and group lists to assist in single sign-on and Authentication Server services.

There remains, at all times, a one-to-one mapping between the physical machine with the resources being protected and a VRAD with the associated security attributes. The two are updated synchronously, via the use of agents, a security server, and message protocol to ensure that each remains perfectly synchronized.

The VRAD 10 stores entities. An entity is the data structure that forms the starting point for all security-related activities. As such, it describes a minimal set of properties that are considered essential for effective security while being fully extensible. Every entity in a VRAD has a unique key generated without relation to the information that it represents; i.e., nothing concerning the data can be inferred from a knowledge of the information and vice versa. The unique key associated with an entity is called the entity identifier, or eid. The eid is represented using a number of bits, n, making the maximum size of the realm 2° entities. The entity has a security policy associated with it, the security policy being represented by a name in order that policies may be shared by multiple entities in the VRAD. The actual policy is stored in a private part of the VRAD that may only be accessed by security officers.

The attributes that are part of the entity are name, owner, data type, creation timestamp, last modified timestamp and last access timestamp and security policy. The data type attribute points at a data structure that stores attributes particular to the name of the resource that the entity represents. For example, an entity representing a machine would have the data type machine-ID. A machine-ID instance would store the location of the machine, its IP address, and operating system type. Another type of data structure stored in a VRAD is a proxy entity. This provides a reference to an entity or another proxy entity that is managed outside of the realm in which the proxy is defined. The function of a proxy entity is to allow a security server to have access to entities outside of the realm without being responsible for their management and to remove the need for the generation of globally-unique entity identifiers across all realms within the enterprise. A proxy entity has a unique key (eid) similar to an entity and a URL that stores the location of the VRAD where the actual entity is stored. The URL consists of two pieces of information. First, the protocol, host and port for a remote security server is present. Second, the eid in the remote VRAD is present. A proxy entity can be thought of as a "pointer" to the actual entity. It should be noted that eids are unique within the realm, i.e., no two entities, proxy entities or an entity and a proxy entity can have the same eid.

When information on the actual entity is required, the GPE server managing the realm in which the entity is actually stored is contacted and the information retrieved using the InterRealm Security Protocol (IRSP). All relationships between entities are stored in a single data strucmre known as the Entity Relationship (ER) data structure. A one-to-one relation between two entities is stored as a single instance of an ER data structure. A one-to-many, many-to-one or many-to-many relationship is represented as several instances of ER data structures. The ER data structure stores the two entities involved in a relationship, the name of the relationship and a qualifying operator. For example, an ER data strucmre can be used to store the relationships, "A may read B" and "A may not read B." The difference in representation between the examples in the previous sentence in the value of the associated ER operator. Relationship data structures are used in policies associated with entities to respond to requests for access to an entity. The parent-child relationships that define the structure of a VRAD are stored using ER data structures. A combination of one or more VRADs is called a Realm. A Realm contains all resources being protected, all users allowed access to those resources, all groups with which those users can be associated, and all physical machines (and their addresses) that represent the Realm. A realm defines a default security policy that is used when individual entities do not have a policy defined for them. This policy ensures that requests for access to resources will always be resolved.

Realms may act as containers for other realms managed by other security servers. The enterprise realm is special in that it acts as a container for all other realms in the enterprise. If an entity is stored within a particular realm, its security is managed by that realm.

Each entity stored within the VRAD has additional attributes and relationships to other entities associated with it. These include unique name, Entity ID, mandatory controls, etc. An entity includes a reference to another data strucmre by name that contains non-security specific information. For example, the physical location of a machine might be stored and used in a mediation function to prevent information legal in one country from being transmitted to a country in which that information is illegal.

Since the strucmre is tree-like, it is easy to manipulate the strucmre via security messaging protocol designed to assist in walking a tree-like strucmre, and performing actions against it. Any tree-traversal algorithms can be utilized to manipulate the information stored within a VRAD.

VRAD trees can be linked across security servers in order to provide a security solution across an enterprise. The proxy entity concept is used to achieve this.

VRAD trees contain only entity or proxy entity data structures. The VRADs for the resources associated with each machine are stored as subtrees within the VRAD for the realm. The root of this tree is always an entity representing the GPE itself. This entity is called the realm root. The parent of the realm root is a proxy entity that represents the realm root, which is one level up in the enterprise security hierarchy. In the case of the enterprise realm root, it is its own parent. It is possible to walk to any realm in the enterprise by walking to the parent of the realm root given appropriate security permissions. When the parent of the realm root is requested, the proxy entity for the parent is retrieved. The IRSP is used to retrieve the eid of the remote entity if the requesting user has permission to do so. Referring to Figure 2, two realms 10,, 10₂ are represented. Realms 10, and 10₂ are managed by GPE, and GPE₂ respectively. When an agent walks from Machine, to Files,, GPE, (realm root), then to the parent GPE (realm root of a parent realm), and finally to Users₂ on the remote GPE, the eid of Users₂ under GPE₂ is returned. This eid is served up to the user and a new proxy created within realm,. Garbage collection of this proxy entity occurs when the user no longer needs to access the remote entity. While the above example has demonstrated linking of realms through the realm root entity, cross linking of VRADs at other points within the realm is possible. For example, in Figure 2, a child directory of machine₄ in realm₂ is managed by realm,. A proxy for dir₂₂ is maintained in realm₂ and a proxy for the root directory of machine., is stored in realm,. Walking from the root directory of machine,, takes the user to dir₂₂ in realm,. Walking to the children of dir₂₂ causes proxy entities to be generated in realm₂ that are removed when the user tells the system that they may be discarded or when the user logs out from the system.

The invention provides a flexible approach to file security that is consistent across different operating systems.

Claims

We claim:

1. A method of controlling access to computer data, comprising the steps of: creating a real file system for storing said data; creating a virtual file system that mirrors said real file system but lacks the stored data; and storing attributes pertaining to the files in said file system at corresponding locations in said virtual file system.

2. A method as claimed in claim 1, wherein said attributes are security attributes.

3. A method as claimed in claim 2, wherein said virtual file system manages the security attributes stored within it.

4. A method as claimed in claim 3, wherein said virtual file system mediates access to said computer data in said real file system based on said stored attributes in said virtual file system.

5. A method as claimed in claim 4, wherein said virtual file system is organized in a tree strucmre representing parent-child relationships found in said real file system.

6. A method as claimed in claim 5, wherein said attributes are stored as entities describing the security properties of a corresponding file in said real file strucmre.

7. A method as claimed in claim 6, wherein each said entity has a unique key generated without relation to the data whose attributes it describes.

8. A method as claimed in claim 7, wherein each said key has a security policy associated with it to permit policies to be shared by multiple entities within the virtual file system.

9. A method as claimed in claim 7, wherein each said entity stores the following attributes: name, owner, data type, creation timestamp, last modified timestamp, last access timestamp, and security policy.

10. A method as claimed in claim 7, wherein said virtual file system also stores proxy entities referencing an actual entity stored in a different virtual file system to permit access to entities stored in said different virtual file system without requiring said first mentioned file system to be responsible for its management.

11. A method as claimed in claim 7, wherein all relationships between entities are stored in a single entity data strucmre.

12. A method as claimed in claim 7, wherein a plurality of said virtual file systems are linked through their roots.

13. A method as claimed in claim 7, wherein a plurality of said virtual file systems are cross linked at points on the tree strucmre.

14. A virtual resource attribute directory comprising a shadow directory strucmre miπoring a real file strucmre and storing attributes of files in said real file strucmre without the associated data.

15. A virtual resource attribute directory as claimed in claim 14, wherein said shadow directory strucmre is a tree strucmre.

16. A virtual resource attribute directory as claimed in claim 14, wherein said attributes are stored as entities describing the security properties of a coπesponding file in said real file strucmre.

17. A virtual resource attribute directory as claimed in claim 16, wherein each said entity has a unique key generated without relation to the information whose attributes it describes.