Security platform and method using object oriented rules for computer-based systems using UNIX-line operating systems

• US 5,720,033 A
• Filed: 07/25/1995
• Issued: 02/17/1998
• Est. Priority Date: 06/30/1994
• Status: Expired due to Term

• Current Assignee: Lucent Technologies, Inc. (Nokia Corporation)
• Original Assignee: Lucent Technologies, Inc. (Nokia Corporation)
• Inventors: Deo, Umesh
• Primary Examiner(s): Black, Thomas G.
• Assistant Examiner(s): Alam, Hosain T.
• Application Number:
  US08/506,531
• Time in Patent Office: 938 Days
• Field of Search: 395/186, 395/616, 395/614, 395/611, 395/612, 395/613, 395/187.01, 395/188.01
• US Class Current: 726/2
• CPC Class Codes: G06F 21/6218 to a system of files or objects, e.g. local or distributed file system or database

Abstract

A security platform, for stand-alone or networked processors using UNIX or similar operating systems, limits access to system resources, including software and hardware, by personnel using the system and by other resources within the system. The platform implements a rules-based naming and rule convention for types of access of security interest to one or more served application programs, providing rule sets each of which associate an access type with a subject and, optionally, one or more objects to which are compared access demands made by the served application to the platform in the same form as the rule sets to determine whether the access demanded is permissible. Internal platform security is provided by limiting users who can modify the platform and its resident rules.

Claims

1. A security platform for a UNIX-based system comprising:

at least one rule, each rule directly defining a type of access in terms of subject, a subject being an entity type for which access is permitted by the rule and which encompasses users, system resources and other entity types, and two or more objects, an object being the entity types to which the access relates in the order listed and which encompass users, system resources and other entity types;

means for comparing requested access by an entity type, requested access being defined by an access demand which identifies the access type of interest and defines that access type in terms of subject and objects, to the defined at least one rule to determine if requested access is permitted based upon the correspondence between the terms making up the requested access with the terms defining the at least one rule; and

means for providing a positive response when access is permitted and a negative response when access is not permitted.

2. The security platform of claim 1, wherein the comparing means

determines if the access type identified in the access demand is the same as the access type of the at least one rule, and if no match exists, determines that access is not permitted;

if a match exists between the access demand and the at least one rule, determines if the subject of the access demand is the same as the subject of the at least one rule with which the access type matched, and, if no match exists, determines that access is not permitted;

if a match exists between the access demand subject and the subject of the at least one rule with which the access type of the access demand matched, determines if the first object of the access demand is the same as the first object of the at least one rule with which the access type and subject matched, and, if no match exists between the first objects, determines that access is not permitted;

if there exists a match between the first objects, continues to attempt to find matches through the nth object of the access demand and the nth object of the at least one rule, and if no match exists for any object, determines that access is not permitted; and

if all n objects for the access type match all n objects in the at least one rule, determines that access is permitted.

3. The security platform of claim 2, wherein the comparing means determines for any unmatched subject of the access demand if a rule exists within the platform which defines the unmatched subject as a member of a group of subjects, a class, and determines if the class is the subject of the at least one rule with which the access type matched that of the access demand, and if the class is not the subject, determines that access is not permitted, and if the class is the subject, accepts the class as a match for the any unmatched subject.

4. The security platform of claim 3, wherein the comparing means determines for any unmatched object of the access demand if a rule exists within the platform which defines the unmatched object as a member of a group of objects, a class, and determines if the class occupies the object position in the at least one rule with which the access type, subject and preceding objects match that of the access demand, and if the class does not occupy the object position, determines that access is not permitted, and if the class does occupy the object position, accepts the class as a match for the any unmatched object.

5. The security platform of claim 4, further comprising:

a rules file in which a persistent copy of the at least one rule is kept;

shared memory in which a non-persistent copy of the at least one rule is kept; and

wherein the comparing means searches the shared memory for the at least one rule.

6. The security platform of claim 5, further comprising:

means for limiting modification of the platform to properly authorized users including defining the request to modify the platform as an access demand in which the user is identified as the subject of the access demand and the comparing means determines if at least one rule matches the access demand and permits access.

7. The security platform of claim 6 in which the means for limiting modifications also includes validating a security code.

8. The security platform of claim 7, further comprising:

a daemon process which modifies rules in the shared memory and in the rules file consistent with the input from a properly authorized user;

then sends the modifications to any other daemon process in the system;

a message queue which accepts all messages input to the platform related to modification of the platform and which keeps any other user'"'"'s input from the daemon process until the daemon process has completed modifying rules consistent with the input from the immediate authorized user.

9. A method for limiting access within a computer system having a UNIX-like operating system to provide security therefor, comprising the steps of:

specifying each type of access of interest by an identifier;

defining, for each type of access of interest, at least one rule which identifies the access type by the identifier and specifies access in terms of a user for which the access of interest is defined as permitted and two or more system resources to which the access of interest relates in the order listed in the rule;

accepting an access demand sent by a user which identifies the access type of interest, and demands access in terms of the user for which access is demanded and the system resources to which the access demand relates in the order listed in the access demand;

matching the access demand against the at least one rule for correspondence between the access type of interest, the user and the system resources in the order stated in the access demand with the identifier, user and system resources in the order stated in the at least one rule; and

sending a positive access response for a direct match.

10. The method of claim 9 further comprising the steps of:

if there is no direct match between the access demand and the at least one rule, determining if there is at least one rule which identifies the user as a member of a class of users and, if there is,

determining if the class is the user of the at least one rule with which the access type matched that of the access demand;

if the class is not the user, sending a negative access response;

if the class is the user, continuing as though there were a match between the user identified in the access demand and the user in the at least one rule;

if there is a user correspondence, determining if there is a rule which identifies the first through nth system resource in the same position as the position of the first through nth system resource identified in the access demand; and

if the resources of the access demand match the resources and positioning in the at least one rule, providing a positive access signal.

11. The method of claim 10 further comprising the steps of:

if there is a user match, determining, for any unmatched first through nth resources of the access demand, if a rule exists which defines the unmatched resource as as a member of a group of resources;

determining if the class of resources occupies the position in the at least one rule with which the access type, user and preceding resources match that of the access demand;

if the class does not occupy the resource position, providing a negative access response; and

if the class does occupy the resource position, proceeding as though there were a match.

12. The method of claim 9 further comprising the steps of:

validating an access demand from a first user to modify at least one rule;

permitting the first user to access the at least one rule for modification;

prohibiting other access to the at least one rule until the modified at least one rule is updated throughout the computer system;

storing in order requests to access the at least one rule;

determining when modification of the at least one rule by the first user is complete;

upon modification completion, updating the at least one rule in the location within the computer system where the at least one rule is accessed by the first user to reflect the modified at least one rule;

locating every other location in the computer system where the at least one rule resides; and

updating the at least one rule in every other location consistent with the modification at the location of access by the first user.

13. A security platform for a UNIX-based system comprising:

at least one rule, each rule directly defining a type of access in terms of subjects, a subject being an entity type for which access is permitted by the rule and which encompasses users, system resources and other entity types, and two or more objects, an object being the entity types to which the access relates in the order listed and which encompass users, system resources and other entity types;

means for comparing requested access, requested access being defined by an access demand which identifies the access type of interest and defines that access type in terms of subject and objects, to the defined at least one rule to determine if requested access is permitted based upon the correspondence between the terms making up the requested access with the terms defining the at least one rule;

wherein the comparing means determines if the access type identified in the access demand is the same as the access type of the at least one rule, and if no match exists, determines that access is not permitted;

but if a match exists between the access demand and the at least one rule, the comparing means determines if the subject of the access demand is the same as the subject of the at least one rule with which the access type matched;

if a match exists between the access demand subject and the subject of the at least one rule with which the access type of the access demand matched, the comparing means determines if the first object of the access demand is the same as the first object of the at least one rule with which the access type and subject matched;

if there exists a match between the first object of the access demand and the first object of the at least one rule, the comparing means continues to attempt to find matches through the nth object of the access demand and the nth object of the at least one rule; and

if all n objects for the access type match all n objects in the at least one rule, the comparing means determines that access is permitted;

and wherein the comparing means further determines for any unmatched subject of the access demand if a rule exists within the platform which defines the unmatched subject as a member of a group of subjects, a class, and determines if the class is the subject of the at least one rule with which the access type matched that of the access demand, and if the class is not the subject, determines that access is not permitted, and if the class is the subject, proceeds as though there were a match,

and wherein the comparing means also determines for any unmatched object of the access demand if a rule exists within the platform which defines the unmatched object as a member of a group of objects, a class, and determines if the class occupies the object position in the at least one rule with which the access type, subject and preceding objects match that of the access demand and if the class does occupy the object position, proceeds as though there were a match;

and wherein the comparing means determines that access is not permitted if no match exists for the access type, the subject, or an object and determines that access is permitted if a match exists for the access type, the subject and the objects between the access demand and the at least one rule;

means for providing a positive response when access is permitted and a negative response when access is not permitted;

a rules file in which a persistent copy of the at least one rule is kept;

shared memory in which a non-persistent copy of the at least one rule is kept; and

wherein the comparing means searches the shared memory for the at least one rule;

means for limiting modification of the platform to properly authorized users including defining the request to modify the platform as an access demand in which the user is identified as the subject of the access demand and the comparing means determines if at least one rule matches the access demand and permits access,

the means for limiting modification includes validating a security code;

a daemon process which modifies rules in the shared memory and in the rules file consistent with the input from a properly authorized user;

then sends the modifications to any other daemon process in the system; and

a message queue which accepts all messages input to the platform related to modification of the platform and which keeps any other user'"'"'s input from the daemon process until the daemon process has completed modifying rules consistent with the input from the immediate authorized user.

14. A method for limiting access within a computer system to provide security therefor, comprising the steps of:

specifying each type of access of interest by an identifier;

defining, for each type of access of interest, at least one rule which identifies the access type by the identifier and specifies access in terms of users, users being either persons or system resources, for which the access of interest is defined as permitted and two or more system resources to which the access of interest relates in the order listed in the at least one rule;

accepting an access demand sent by a user which identifies the access type of interest, and demands access in terms of the user for which access is demanded and the system resources to which the access demand relates in the order listed in the access demand;

matching the access demand against the at least one rule;

sending a positive access response for a direct match;

if there is no direct match between the access demand and the at least one rule, determining if the at least one rule has an identifier which matches the access type of interest of the access demand;

if there is no match between the at least one rule identifier and the access type of interest of the access demand, sending a negative access response;

if there is a match between the at least one rule identifier and the access type of interest of the access demand, determining if there is a match between the user in the access demand with the user in the at least one rule for which the identifier matched the access type of interest;

if there is no match between the user in the access demand and the user in the at least one rule, determining if the user is a member of a class of users and, if it is, determining if the class is the user of the at least one rule for which the access identifier matched that of the access type of interest in the access demand;

if the class is not the user, sending a negative access response;

if the class is the user, continuing as though there were a match between the user identified in the access demand and the user in the at least one rule;

if there is a user match, determining if the at least one rule in which the identifier and the user matches respectively the access type and user of the access demand identifies the first through nth resources in the same position as the position of the first through nth resources identified in the access demand;

if the resources match, providing a positive access signal;

if there is not a match of the first through n resources between the at least one rule and the access demand, determining for any unmatched first through nth resources of the access demand, if a rule exists which defines the unmatched resource as a member of a class of resources;

determining if the class of resources for the unmatched resource occupies the position in the at least one rule with which the access type, user and preceding resources match that of the access demand;

if the class does not occupy the resource position, providing a negative access response;

if the class does occupy the resource position, proceeding as though there were a match;

sending a negative access response if a resource at the location defined in the access demand is unmatched by a comparable resource in the at least one rule; and

sending a positive access response if the access type, user and resources at the location defined in the access demand is matched by a comparable identifier, user, and resources in the at least one rule.

15. The method of claim 14 including the additional steps of:

controlling modification of rules to permit only one authorized user access to a rule at a time;

upon completing a rule modification, providing the modified rule to each place in the system in which the rule is resident and replacing the affected rule with the modified rule;

storing in order all messages from other authorized users and withholding access by any other authorized user until dissemination of the modified rule is complete.

16. The method of claim 15 including the additional steps of:

determining whether a user is authorized access to modify rules, determining access authorization including the steps of;

requesting the user initiating the access demand respond with an security code; and

validating the security code provided.