Role based access controls

CROSS REFERENCE TO OTHER APPLICATIONS

p-0002This application claims priority to U.S. Provisional Patent Application No. 60/653,809 entitled Enterprise-Wide Access Control Systems filed Feb. 16, 2005 which is incorporated herein by reference for all purposes.

BACKGROUND OF THE INVENTION

p-0003Identity management, provided by products such as Novell eDirectory and Microsoft ActiveDirectory can be conceptualized as a database of individual users and one or more credentials that correspond to the users, such as a password. Rudimentary access controls may be enforced by the identity management products, such as by defining that a specific user may read the files in one directory, while another user may not. Similarly, a group of specified users (e.g., Alice, Bob, and Charlie) may be granted permission to modify a particular file, while other users may be granted no access to the file at all. In each case, considerable manual effort is required on the part of an administrator to configure to which resources a user is entitled access, and to what extent access should be granted. One effect is that the resulting access controls may be arbitrarily applied—two users having the same job, requiring the same access to the same files may wind up with different access, depending on which administrator configured their respective accounts.

p-0004Additionally, to the extent that access controls are provided by identity management products, they are enforced at the application layer. Thus, it is possible for an attacker to circumvent the access controls imposed by typical identity management tools.

p-0005Therefore, it would be desirable to have a better way to secure a computer system.

BRIEF DESCRIPTION OF THE DRAWINGS

Various embodiments of the invention are disclosed in the following detailed description and the accompanying drawings.

<figref idrefs="DRAWINGS">FIG. 1A</figref> is a block diagram illustrating an embodiment of a system having role based access controls.

<figref idrefs="DRAWINGS">FIG. 1B</figref> is a flow chart illustrating an embodiment of a process for providing role based access controls.

<figref idrefs="DRAWINGS">FIG. 2</figref> is a flow chart illustrating an embodiment of a process for creating a profile.

<figref idrefs="DRAWINGS">FIG. 3A</figref> illustrates an embodiment of a profile.

<figref idrefs="DRAWINGS">FIG. 3B</figref> illustrates an embodiment of a profile.

<figref idrefs="DRAWINGS">FIG. 3C</figref> illustrates an embodiment of a profile.

<figref idrefs="DRAWINGS">FIG. 3D</figref> illustrates an embodiment of a profile.

<figref idrefs="DRAWINGS">FIG. 4A</figref> illustrates an embodiment of a program profile.

<figref idrefs="DRAWINGS">FIG. 4B</figref> illustrates an embodiment of a program profile.

<figref idrefs="DRAWINGS">FIG. 5</figref> illustrates an example interaction with an analyzer.

<figref idrefs="DRAWINGS">FIG. 6</figref> illustrates an embodiment of a profile.

<figref idrefs="DRAWINGS">FIG. 7</figref> illustrates a portion of an embodiment of a program profile.

DETAILED DESCRIPTION

p-0019The invention can be implemented in numerous ways, including as a process, an apparatus, a system, a composition of matter, a computer readable medium such as a computer readable storage medium or a computer network wherein program instructions are sent over optical or electronic communication links. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. A component such as a processor or a memory described as being configured to perform a task includes both a general component that is temporarily configured to perform the task at a given time or a specific component that is manufactured to perform the task. In general, the order of the steps of disclosed processes may be altered within the scope of the invention.

p-0020A detailed description of one or more embodiments of the invention is provided below along with accompanying figures that illustrate the principles of the invention. The invention is described in connection with such embodiments, but the invention is not limited to any embodiment. The scope of the invention is limited only by the claims and the invention encompasses numerous alternatives, modifications and equivalents. Numerous specific details are set forth in the following description in order to provide a thorough understanding of the invention. These details are provided for the purpose of example and the invention may be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the invention has not been described in detail so that the invention is not unnecessarily obscured.

p-0021<figref idrefs="DRAWINGS">FIG. 1A</figref> is a block diagram illustrating an embodiment of a system having role based access controls. In the example shown, a kernel <b>102</b>, a policy module <b>104</b>, a directory system <b>106</b>, an analyzer <b>108</b>, a log <b>110</b>, a role shell <b>112</b>, and a profile <b>114</b> are included. In this example, system <b>100</b> is a SUSE Linux system. The role shell is described herein in terms of the bash command interpreter. Other platforms, such as MICROSOFT WINDOWS may also be used, and the techniques described herein may be adapted as appropriate. Similarly, in this example, policy module <b>104</b> is a Linux loadable kernel module. Policy module <b>104</b> may be adapted for other architectures as appropriate.

p-0022Roles can be created, managed, allocated to users, and removed as organizational needs dictate. Examples of roles include functions, such as “helpdesk,” levels of competence, such as “junior system administrator,” departments, such as “human resources,” and job titles, such as “Chief Financial Officer (CFO).”

p-0023Each role may have multiple users associated with it (e.g., users Peter, Jane, and Barbara may all have a “secretary” role), and a user may have multiple roles (e.g., Jack may have all of the following roles: “CFO,” “Board of Directors,” “Sales,” and “Management”).

p-0024By providing a layer of indirection (i.e., associating a role with a user), if the user's job description ever changes, for example, if the user is promoted, adjusting the user's access to resources can be accomplished quickly and cleanly.

p-0025Suppose, for example, that Bob currently works as a junior engineer. He might have a role of “engineer.jr,” indicating that he works in the engineering department and is a junior level employee. If Bob joins the sales department as a sales engineer, he will need access to different resources. As a junior engineer, Bob may have had the ability to commit changes to the code base. He may also have had the ability to read system logs, but not to reboot machines—something a senior engineer (with a role of engineer.sr) might be allowed to do. As a sales engineer, he may no longer need commit access, but may need access to new resources, such as customer lists and sales documents. Thus, by revoking Bob's role of engineer.jr and associating him with a new role of “sales.engineer,” Bob effectively has immediate access to only those resources which he should have, commensurate with his role. Similarly, new employees could be given a role, “new_hire” that limits their access to resources until they've signed non disclosure agreements or other employment paperwork.

p-0026In this example, a role shell <b>112</b> is selected for creation and profiled by analyzer <b>108</b> to create profile <b>114</b>. A profile can describe the ability to access files and can also describe permission to do a complex set of operations, and may be specific to the enterprise.

p-0027Directory system <b>106</b> includes a database of individual users and credentials associated with those users. In some embodiments, directory system <b>106</b> is physically separate from system <b>100</b>. For example, directory system <b>106</b> may be a product such as Novell eDirectory or Microsoft ActiveDirectory and modifications may be made, as applicable, to allow for the translation of directory system <b>106</b>'s information into a syntax that system <b>100</b> can make use of. As described in more detail below, in various embodiments system <b>100</b> controls file access, network access, or both. In various embodiments, profiles control local application and/or user access to local resources, remote resources, or both local and remote resources.

p-0028In some embodiments, all of the users defined in directory system <b>106</b> are users of system <b>100</b>. In some embodiments, only a subset of users defined in directory system <b>106</b> are users of system <b>100</b>. This may be the case, for example, in a corporate setting, where employees may have limited access to a web-based email account, but no other access to nodes on the corporate network, where other employees, such as system administrators, may have extensive access to several platforms.

p-0029The profiles described herein can be created, installed, and enforced, even for programs, users, and roles that do not yet exist on a given node. Even if those programs, users, and/or roles are subsequently created on the node, the policy will still apply.

p-0030Profile <b>114</b> is created in some embodiments by starting with a default profile and refining the profile by executing commands and logging the access requests that role shell <b>112</b> makes in a log <b>110</b>. For example, attempts at reading libraries and writing to particular directories are recorded in log <b>110</b>. In some embodiments, profile <b>114</b> is generated at least in part by having a user knowledgeable about the legitimate tasks a user having a role with which the profile is associated is and/or may be required to perform, such as a trusted or monitored holder of the role, another user knowledgeable about the role and legitimate activities performed by users having the role, an administrator using a predetermined (e.g., scripted) set of operations identified as being associated with the role, etc., and have such a user perform such tasks using role shell <b>112</b>. Analyzer <b>108</b> evaluates log <b>110</b> and interacts with an administrator to determine an appropriate set of rules to cover the logged behavior.

p-0031A policy module <b>104</b> loaded in kernel <b>102</b> is configured to enforce the access controls specified in profile <b>114</b> against a user that has a role shell <b>112</b>. The restrictions listed in the profile (also referred to herein as a “policy”) typically complement any access controls already provided by the underlying system, also known as native access controls. Thus, for example, any file access must be allowed under both the native access controls, and any controls provided in the profile for access to be granted to the user that has a role shell <b>112</b>.

p-0032A user-level parser (not depicted) reads profiles such as profile <b>114</b> from a specified location, such as /etc/subdomain.d/* and converts the textual representation of profiles into kernel data structures. The parser inserts the profiles into kernel <b>102</b> by, such as by using a sysctl( ) interface. As described in more detail below, applications may also have profiles.

p-0033Relevant system calls (e.g., open, exec, read) are modified to check if the calling process is confined. If so, the request is referred to the policy module for further inspection. When a confined process makes a request that is permitted, the policy module returns normally. When a confined process attempts to perform a file operation that is not permitted, a syscall returns with a permission error. In some embodiments, kernel <b>102</b> also generates a syslog entry describing the attempted access violation. This information can be used by a variety of other security features, such as an intrusion detection system, as appropriate.

p-0034<figref idrefs="DRAWINGS">FIG. 1B</figref> is a flow chart illustrating an embodiment of a process for providing role based access controls. The process begins at <b>152</b> when a profile associated with a role is generated. In some embodiments, the profile is created and/or refined at least in part by observing authorized behavior and/or use associated with the role and generating one or more rules to ensure that such observed behavior and/or use are permitted. At <b>154</b>, the profile is enforced with respect to one or more users associated with the role.

p-0035<figref idrefs="DRAWINGS">FIG. 2</figref> is a flow chart illustrating an embodiment of a process for creating a profile. In some embodiments portion <b>152</b> of <figref idrefs="DRAWINGS">FIG. 1B</figref> includes the process depicted in <figref idrefs="DRAWINGS">FIG. 2</figref>. The process begins at <b>202</b> when an indication that a role is to be profiled is received. In some embodiments, this is accomplished by an administrator entering a command such as “generate-profile <role>”. For example, an administrator could begin at <b>202</b> by entering a command such as “generate-profile /bin/hrbash” in a console window, to indicate that the role shell “hrbash” is to be profiled for a human resources role. In other embodiments, other interfaces, such as the YaST graphical user interface, are used in lieu of or in addition to the console, as appropriate.

p-0036In some embodiments, an automated method is used to help determine which roles should be profiled. For example, a suggested list of common roles (e.g., basic user, junior administrator, super user) can be presented to an administrator for potential profiling.

p-0037At <b>204</b>, a profile (also referred to as an “initial profile”) is created. In some embodiments, if a profile already exists on the system <b>204</b> is omitted. In some embodiments, role shells are hard links that point at a standard system shell, such as /bin/bash. If “generate-profile /bin/hrbash” is entered at <b>202</b>, at <b>204</b>, it is determined whether /bin/hrbash exists. If not, the administrator is presented with the option of creating a hard link. If /bin/hrbash does exist, the administrator may be presented other choices, such as the ability to review the existing profile, create a new profile on top of the old one, create a new profile under a different name (e.g., /bin/ceobash), etc.

p-0038At <b>206</b>, it is determined whether the profile being generated is sufficient. In some embodiments, the profile is determined at <b>206</b> to be sufficient if the profile permits most to all of the activities that a user having the role embodied in role shell <b>112</b> is legitimately supposed to perform. As described in more detail below, one way of verifying whether a profile is sufficient is to run role shell <b>112</b> and perform assorted legitimate tasks, and then confirm that log <b>110</b> is free of access violations attributable to role shell <b>112</b>.

p-0039At <b>208</b>, the profile is refined. As described in greater detail below, one way of accomplishing this is to enter a learning mode in which attempts by the user to access files or other resources are logged, but attempts to access a file or other resource that the profile in its then current form does not allow are not blocked. In some embodiments, only access attempts the profile in its then current form does not allow are logged. In some embodiments, where possible, events are generalized, e.g., through interacting with an administrator, to refine the profile, e.g., by defining and/or modifying a (generalized, if possible) rule such that the observed access attempt would in the future be permitted under the profile. For example, in some embodiments for each event, where possible one or more generalizations of the event are suggested, offering the administrator the opportunity to choose to define a narrow rule that would permit the specific access attempt observed or a more general rule that would allow access to resources of a general class of which the specifically accessed resource is a member, e.g., by allowing access to all files in a particular library, as opposed to allowing access just to the specific file the application was observed to access.

p-0040The process ends at <b>210</b> when it is determined that the profile being generated is sufficient.

p-0041In some embodiments, the profile is updated if it is subsequently determined that additional functionality should be permitted (or denied) to a user associated with a role with which the profile is associated. For example, if a person working for the HR department were assigned a new function or task, such as performing helpdesk services, such as password resetting, in some embodiments the profile for the user's role would be updated to expressly allow access to the resources required to perform the new function or task. As described in more detail below, features of multiple roles can be combined in assorted ways.

p-0042Four example profiles for four roles are presented in conjunction with <figref idrefs="DRAWINGS">FIGS. 3A-3D</figref>. The first (<figref idrefs="DRAWINGS">FIG. 3A</figref>) is an HR role that can add and delete user accounts, but not manipulate them. The second (<figref idrefs="DRAWINGS">FIG. 3B</figref>) is a helpdesk role that can change user passwords and perform other helpdesk functions but can not add or delete users. The third (<figref idrefs="DRAWINGS">FIG. 3C</figref>) is a composition of the HR and helpdesk roles. The fourth (<figref idrefs="DRAWINGS">FIG. 3D</figref>) is an indirect composition of the HR and helpdesk roles. The profiles presented in conjunction with <figref idrefs="DRAWINGS">FIGS. 3A-3D</figref> are simplified and could easily be manually created by an administrator. A more sophisticated version of the HR role is given in conjunction with <figref idrefs="DRAWINGS">FIGS. 5 and 6</figref>.

p-0043<figref idrefs="DRAWINGS">FIG. 3A</figref> illustrates an embodiment of a profile. This profile is of the role shell, “/bin/hrbash” (<b>302</b>), and is a role that indicates, for example, that a user associated with the role works in the human resources department. To enforce the profile against a user having an HR role, the user's default login shell is set to /bin/hrbash. Whenever the user accesses resources, their activities will be constrained by the profile associated with their role shell.

p-0044The profile shown in <figref idrefs="DRAWINGS">FIG. 3A</figref> includes information such as a list of files that a user having role shell /bin/hrbash may access (<b>304</b>), and the corresponding operations the user may perform (<b>306</b>) on those files. The access controls granted to a user having a particular role shell are sometimes referred to collectively as the “domain” of activities that a user having that role shell is authorized to perform.

p-0045In this example, read (denoted “r”) and execute access (denoted “x”) have been granted to role shell hrbash itself (<b>308</b>), allowing a user to spawn multiple instances of the shell as needed. As described in more detail below, in some embodiments the additional instances of the shell will also be confined. The shell is also permitted read and execute access to two additional files, in this case programs /usr/sbin/useradd (which can be used to create a new user) and /usr/sbin/userdel (which can be used to delete a user). As described in more detail below, programs, such as useradd, may also have profiles confining their behavior. Also as described in more detail below, various methods may be used to specify the type of execute access that may be granted.

p-0046The profile shown in <figref idrefs="DRAWINGS">FIG. 3A</figref> has three #includes (<b>310</b>). A “#include” is a directive that can be used to simplify a profile such as by either abstracting common tasks, or using chunks of other programs. For example, abstractions can include access to authentication mechanisms, graphics requirements, and system accounting. The administrator can also define abstractions.

p-0047Here, the first, “standard/base” is a set of file access permissions that are needed by many programs, such as read permission for glibc. The second, “standard/consoles” helps programs run correctly whether started at a console, a graphical interface, etc. The third, “standard/nameservice” includes accesses required to do user name lookups, DNS lookups, etc.

p-0048<figref idrefs="DRAWINGS">FIG. 3B</figref> illustrates an embodiment of a profile. This profile is of the role shell, “/bin/helpbash” (<b>312</b>), and is a role that indicates, for example, that a user associated with the role works at a helpdesk. In this profile, read and execute access is granted to /usr/bin/passwd (which can be used to change a user's password), and /usr/sbin/usermod (which can be used, for example, to change a user's home directory, shell, etc.). In this profile, no access is granted to the useradd or userdel programs.

p-0049<figref idrefs="DRAWINGS">FIG. 3C</figref> illustrates an embodiment of a profile. This profile (<b>314</b>) combines the permitted activities of both the HR role and the helpdesk role. Specifically, the accesses to /usr/sbin/useradd and /usr/sbin/userdel (<b>316</b>), and the accesses to /usr/bin/passwd and /usr/sbin/usermod (<b>318</b>) that were granted in the profiles depicted in <figref idrefs="DRAWINGS">FIGS. 3A and 3B</figref>, respectively, are included.

p-0050<figref idrefs="DRAWINGS">FIG. 3D</figref> illustrates an embodiment of a profile. This profile (<b>316</b>) also combines the permitted activities of both the HR role and the helpdesk role. Here, however, a layer of indirection is used. Access is granted to the respective role's shells (/bin/hrbash and /bin/helpbash), which in turn allow access to their respective contents.

p-0051<figref idrefs="DRAWINGS">FIG. 4A</figref> illustrates an embodiment of a program profile. In this example, the program being profiled is “passwd,” which can be used to set the password of a user. This program is authorized for use by a person associated with the helpdesk role (<figref idrefs="DRAWINGS">FIG. 3B</figref>) and/or either of the composite roles (<figref idrefs="DRAWINGS">FIGS. 3C</figref> and/or <b>3</b>D).

p-0052In this example, read, write, and link (and unlink) access (denoted “1”) to the files /etc/npasswd (<b>402</b>) and /etc/nshadow (<b>404</b>) has been granted. Shell globbing can also be used to denote resources. For example, read, write, and link access has also been granted for any file in the /etc/ directory that has a prefix of “pwd.” (<b>406</b>). Write access, only, has been granted to /etc/.pwd.lock (<b>408</b>). When “passwd” is called, it is restricted to accessing the above files with the above listed modes (and similarly, the other files listed in the profile with their respective access modes).

p-0053<figref idrefs="DRAWINGS">FIG. 4B</figref> illustrates an embodiment of a program profile. In this example, the program being profiled is “useradd,” which can be used to create a new user. Commands such as useradd and usermod can theoretically be used to create unconstrained root accounts. Special programs, such as “confineduseradd” and “confinedusermod” may be included in system <b>100</b> that enforce policy with respect to such things as what kind of user accounts can be created, what their uid may be, what their default shell can be, and what profile is associated with that shell. These are special cases because the right to add and manipulate users can be conceptualized as a right to create privileges.

p-0054<figref idrefs="DRAWINGS">FIG. 5</figref> illustrates an example interaction with an analyzer. The interaction depicted in this example will produce a role shell for the HR shell that is more comprehensive than the one shown in <figref idrefs="DRAWINGS">FIG. 3A</figref>. At <b>502</b>, an administrator indicates that the role shell “/bin/hrbash” should be profiled. This corresponds with portion <b>202</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>. A hard link is created from /bin/hrbash to /bin/bash, corresponding with portion <b>204</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>.

p-0055At <b>504</b>, the administrator is invited to perform tasks that a person having an HR role would be authorized to execute. In this example, the administrator executes authorized HR tasks in a learning mode, where violations of the profile are logged in a log <b>110</b>, such as /var/log/messages. These logged events represent authorized behavior, unless the administrator through mistake or otherwise executes a task not authorized for the HR role.

p-0056In some embodiments, time markers, hashes, or other hints may be inserted into the log and checked for by the analyzer. These may be used, for example, to help the analyzer follow the execution of the application better, including by creating a tree of events, and other program executions, to create an impression of interactive behavior while profiling.

p-0057In some cases, the role's allowed behaviors may be run in conjunction with a comprehensive test suite or quality assurance (QA) cycle to best reflect how the role will be used in a production environment. If an administrator forgets to exercise key functionality, or new resources are required by the role after the profile has been created, the profile can be updated by repeating portion <b>208</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>.

p-0058In some embodiments, profile generation is decoupled from testing. For example, for roles requiring significant access to many resources, the administrator can request that the QA department execute role tasks in learning mode. The log files can then be collected at the end of the QA test and sent back to the administrator or other entity. The profile refinement process can thus be conducted offline from the role being tested.

p-0059When the administrator is finished executing tasks expected to be performed by persons having the role, at <b>506</b>, the administrator selects an option to parse the log for events. In this example, a default recommended option is enclosed in brackets and will be selected if the administrator hits a default key, such as the Enter key. Other choices may be selected by pressing the appropriate key, such as “F” (<b>508</b>) to end the dynamic analyzer. In other embodiments, other interfaces may be used as appropriate.

p-0060The administrator is now posed a series of questions that correspond to events logged in log <b>110</b> while tasks were executed in role shell <b>112</b> (<b>510</b>). This corresponds with portion <b>208</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>. Some of the specific questions and simplifications described below are applicable only to a SUSE Linux platform. Other questions and simplifications can be used with other platforms as applicable.

p-0061For example, at <b>512</b>, an event in the log indicates that the command, “useradd” was executed. The administrator is presented with several options to incorporate this into the hrbash profile, and a default suggestion is enclosed in brackets.

p-0062When execute access is granted, a variety of methods can be used to address what restrictions should apply to the resulting child process. In this example, the suggested option is that the child process inherit (<b>514</b>) the parent process's profile. This generally prevents the confined shell or application from “escaping” its access controls by executing an unrestricted child process, and is denoted in the resulting profile in some embodiments as mode “ix” (see, e.g., <figref idrefs="DRAWINGS">FIG. 6</figref>). In some cases, however, a child process may require different resources than the parent and other methods of determining what access to grant child processes can be used as appropriate.

p-0063For example, if a child has its own profile, a designation of “px” in the parent profile in some embodiments (e.g., as a result of selecting option <b>516</b>) requires that the child's profile be used when the child is spawned. If “px” is required, but the child does not have a profile, the child is blocked from executing. In other embodiments, a child may run unconfined (denoted “ux” in the profile in some embodiments, see, e.g., <figref idrefs="DRAWINGS">FIG. 7</figref>) (<b>518</b>), or may inherit a profile specified by name or file location (denoted “@x” in some embodiments) (not pictured). In some embodiments, when a child process is encountered, the analyzer automatically causes a profile to be generated for the child if one does not exist.

p-0064“Deny” (<b>520</b>) prevents the shell from executing the specified program. “Abort” (<b>522</b>) ends the analysis, discarding changes. “Finish” (<b>524</b>) closes the analyzer, saving any changes made to the profile.

p-0065At <b>526</b>, an event in the log indicates that the list directory contents command, “ls,” was executed. The “ls” command is a very common system tool, used by many applications in a variety of ways. Allowing it (or other commands such as “mv,” “grep,” etc.) to be separately profiled could lead to an unstable system. Thus, in this example, the only option presented to the administrator is to “inherit” (<b>528</b>) the parent process's profile. The “profile” option is not presented.

p-0066At <b>530</b>, an event in the log indicates that the capability, “chown,” was used. In some embodiments, capabilities are the POSIX.1e draft capabilities. The administrator is presented with the options of allowing the role to have the chown capability (<b>532</b>) or to deny the role the capability.

p-0067At <b>534</b>, an event in the log indicates that a non-executable file was accessed. The administrator selects a directory path (<b>536</b>), then the administrator selects a rule (<b>538</b>). In this example, the resource is a library file, “liblog_syslog.so.1.0.0,” and the role shell requires read access to that resource.

p-0068The administrator's choices for permitting access to the library in this example include a first option that is a generalization that helps maintain compatibility when future versions of the library are installed (<b>536</b>), and a second option that would limit access to that specific library (<b>540</b>). Other globs can be suggested for aspects such as kernel module version numbers, process IDs (e.g., /proc/<pid>/output may be rewritten as /proc/*/output), usernames (for example, when paths look like user directories), locale files, time zone files, system fonts (and other directories which contain content for which when a single file is requested, access to the entire directory should be suggested, such as /etc/profile.d and /etc/sysconfig/powersave/), etc.

p-0069Several rules are presented. In this example, rules include the following: “Allow” grants the program access to the specified resource. “Deny” prevents the program from accessing the specified directory path entry. “Glob” modifies the directory path, for example by using wild cards to include all files in a directory, or other regular expressions (e.g., character alteration, arbitrary numbers of path elements, etc.) as desired. “Glob with extension” wildcards the filename in a path, while retaining the file extension. “New” allows the administrator to manually create a rule. “Abort” ends the log analysis, discarding changes. “Finish” closes the analyzer, saving any changes made to the profile.

p-0070At <b>542</b>, an event in the log indicates that the name service switch configuration file, “/etc/nsswitch.conf,” was accessed. In addition to allowing access to the file itself (<b>544</b>), an abstraction is presented to the administrator (<b>546</b>). Here, “abstractions/nameservice” allows accesses required to do user name lookups, DNS lookups, etc.

p-0071Program chunks can be used to allow local policies to be created while leaving the underlying profiles standardized across multiple servers. Other frameworks can also be used so that an administrator can easily add site-specific glob suggestions and site-specific include files that will be suggested if they match access requests.

p-0072At <b>548</b>, an event in the log indicates that a temporary file, “/etc/passwd.tmp3gt91P,” was accessed. In addition to allowing access to the file itself (<b>550</b>), a suggestion is made to allow access to all temporary files having the form “/etc/passwd.*” (<b>552</b>). To allow read access to all files of the form “/etc/passwd.tmp*,” the administrator could select GlobWithExt. To specify a new rule, the administrator could select New and enter the desired rule.

p-0073In some embodiments, the list of generalizations that can/will be presented are stored in a single place, such as a file called logprof.conf, which can be readily modified by an administrator or user as applicable. In this example file, patterns and responses can be encoded so that when the dynamic profile generator sees a file access of “pattern,” it will suggest a generalization of “response.” The “response” can include such things as a glob generalization, a kind of execute permission to suggest (e.g., px, ix, or ux), or a directive not to profile a particular application.

p-0074When events are satisfied by existing profile elements, they are not presented to the administrator, whether they were in the profile at the beginning of the session, or whether they were recently added. When an administrator adds a rule that is a superset of one or more previous entries, the subsumed rules are removed from the profile.

p-0075<figref idrefs="DRAWINGS">FIG. 6</figref> illustrates an embodiment of a profile. This profile, for /bin/hrbash, was created as the result of the analysis/interaction performed in conjunction with <figref idrefs="DRAWINGS">FIG. 5</figref>. In this example, the entries in the completed profile were alphabetized, as were the corresponding access modes. The decision made at <b>514</b> in <figref idrefs="DRAWINGS">FIG. 5</figref> is recorded at <b>602</b>. The decision made at <b>528</b> in <figref idrefs="DRAWINGS">FIG. 5</figref> is recorded at <b>604</b>. The decision made at <b>532</b> in <figref idrefs="DRAWINGS">FIG. 5</figref> is recorded at <b>606</b>. The decision made at <b>536</b> in <figref idrefs="DRAWINGS">FIG. 5</figref> is recorded at <b>608</b>. The decision made at <b>546</b> in <figref idrefs="DRAWINGS">FIG. 5</figref> is recorded at <b>610</b>.

p-0076<figref idrefs="DRAWINGS">FIG. 7</figref> illustrates a portion of an embodiment of a program profile. In this example, the program profiled is the secure shell daemon, or “sshd” (<b>702</b>).

p-0077In some embodiments, access controls can be provided at the granularity of a single native process. Sub-process confinement is gained in some embodiments by using an API called change_hat( ). A confined process can call change_hat( ) to change its confinement to a sub-profile also referred to herein as a “hat.”

p-0078In an application server platform, such as an Apache web server (with built-in execution environments such as mod_perl or mod_php, supporting the PERL and PHP programming languages, respectively), efficient execution of active server pages scripted in PERL, PHP, etc., can come at the expense of security because they all execute in a single process and in a single security domain. By using change_hat( ) each individual script can be executed in a security domain designed just for that script.

p-0079Here, the sshd profile makes use of change_hat( ). The EXEC hat (<b>704</b>) is the default subprofile, used when sshd has authenticated the user. The PRIVSEP hat (<b>706</b>) is a subprofile for handling network input. It is a privilege separated child, in that it has fewer privileges than the EXEC subprofile, so that attacks from unauthenticated users are more tightly confined. Other subprofiles also used, but not pictured, include a subprofile that handles authentication requests from the privilege separated child, and a subprofile for the post-authentication period that is used until the user's shell is spawned.

p-0080In some embodiments, questions such as “what roles may this user assume,” “what resources can that role access,” and “what resources can this user access by assuming all possible roles,” can be answered by a graphical tool that computes the transitive closure of resources that can be accessed by starting from a given profile. “Transitive closure” means following the links of programs that can be executed from the root profile that have their own profile, and thus grant additional resources.

p-0081The graphical representation can be used to show the gatekeeping applications at each domain transition. For instance, a role foo may be able to access the domain for Sendmail, but only by executing the /bin/sendmail application. The sendmail application is thus acting as a gatekeeper to the resources in its profile, and so in principle is not allowing the foo role unqualified access to these resources, but rather is mediating access through the operations that sendmail is willing to perform. If the user with the foo role is an attacker, then they may have a powerful exploit against Sendmail that permits them to hijack the program and coerce it to perform arbitrary computations. The graphical transitive closure form allows arbitrary probabilities to be assigned to each for each gatekeeping application (e.g. high for Sendmail, lower for Postfix). The tool can multiply these probabilities together in a chain, allowing the analyst to assess the combined probability of a role being able to make arbitrary changes to a given file.

p-0082The ability to change a profile can be tantamount to total control over a machine. Example ways of providing security are as follows: Changing a profile requires two properties, (1) the administrator must be root, and (2) the administrator must not be constrained by a profile. This way, an exploitation of a confined process, even running with root's privileges, does not grant the ability to change policy. To allow a confined process mediated ability to change policy, the following requirements could be enforced: (1) The confined processes may execute a specific designated child process as unconstrained; (2) The unconstrained child, if run as root, can make arbitrary policy changes; (3) The unconstrained child is highly trusted software, e.g., small and carefully audited, and should perform appropriate authentication that the requested policy changes are well-formed; and (4) The use of the unconstrained child configuration is generally not permitted in conjunction with regular expressions, and is highlighted in red in SubDomain policy viewing/editing tools.

p-0083In some embodiments, the techniques and system described herein can be used to enforce local policy and delegate privileges to root accounts on local machines, e.g. by confining root to one of each of the predefined tasks listed below, or by confining root to some other role. These tasks include audit, restore, install (can create directories and files, etc.), configure (can modify existing files, etc.), start/stop (ability to run /etc/rc.d/* etc.), run-time execution identity (setting user-IDs of applications), administration privileges (e.g., an oracle DBA may have a different identity than the database itself, and has a different identity than the users), user data (roles for database users), and backup.

p-0084By making policy components composable, administrators can be given variable amounts of privilege, e.g., a sole administrator at a small site may have many different roles at his disposal, while several administrators at a larger site may engage in separation of duty and only have a few roles at each individual's disposal.

p-0085The tasks listed above (audit, restore, etc.) can be defined as compound capabilities. The start/stop role can be achieved by granting permission to execute /etc/rc.d/init.d/lpd to give start/stop capability on lpd. Backup capability can be granted by giving the local administrator access to a backup application (e.g. /usr/bin/amanda) which in turn has a profile that gives read access to the entire file system. Thus the administrator has the capability to back up the system, without having direct read access to all files.

p-0086In some embodiments, a policy agent is an unconfined program on each machine. Administrators of local machines are given a root shell account, but that shell is confined so that the administrator only has capabilities (for example, simple and compound) that are explicitly granted. In this embodiment, none of the files associated with the policy agent are directly accessible by local administrators, preserving the property that local administrators cannot appropriate capabilities for themselves.

p-0087Insider threats can occur where people who have explicit authorization abuse their access. This can be a particular problem where users are permitted to change policies, but also applies generally to the problem of access control, where people abuse access that they were granted. In some embodiments, this is addressed by devising programmable inter-process communications (IPC) filters, so that the kinds of activities that are permitted to flow across IPC channels can be specified. Such programmable filters can be made outboard, so that they can be developed and deployed independent of the basic software functionality (enabling rapid development and separate security enhancement) and can be tuned to particular enterprise installation and configuration (so that organizations don't need to modify source code to change security policy). These techniques can prevent insiders from misusing their access to corrupt enterprise resources in general, and enterprise access control policies in particular.

p-0088Although the foregoing embodiments have been described in some detail for purposes of clarity of understanding, the invention is not limited to the details provided. There are many alternative ways of implementing the invention. The disclosed embodiments are illustrative and not restrictive.