WO2017070209A1 - Techniques pour définir et appliquer des politiques de sécurité à des processus informatiques et systèmes et procédés apparentés - Google Patents

Techniques pour définir et appliquer des politiques de sécurité à des processus informatiques et systèmes et procédés apparentés Download PDF

Info

Publication number
WO2017070209A1
WO2017070209A1 PCT/US2016/057703 US2016057703W WO2017070209A1 WO 2017070209 A1 WO2017070209 A1 WO 2017070209A1 US 2016057703 W US2016057703 W US 2016057703W WO 2017070209 A1 WO2017070209 A1 WO 2017070209A1
Authority
WO
WIPO (PCT)
Prior art keywords
capabilities
computer
computer process
resource
computer system
Prior art date
Application number
PCT/US2016/057703
Other languages
English (en)
Inventor
Scott David Moore
Stephen CHONG
Christos DIMOULAS
Original Assignee
President And Fellows Of Harvard College
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by President And Fellows Of Harvard College filed Critical President And Fellows Of Harvard College
Publication of WO2017070209A1 publication Critical patent/WO2017070209A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/604—Tools and structures for managing or administering access control systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]

Definitions

  • Scripting languages are a standard mechanism by which users and system administrators instruct a computer system to execute operations that access or manipulate system resources. Such tasks may include creating, reading, writing, moving or copying files, executing programs, communicating with a device, and communicating over a network.
  • a processor-driven method for enforcing security policies upon a computer process executing on a computer, the method comprising intercepting, by at least one processor of the computer system, an operation to be performed by the computer process upon a resource of the computer system, identifying, by the least one processor, one or more capabilities associated with the computer process, determining, by the at least one processor based upon the one or more capabilities, whether the operation is permitted, when it is determined that the operation is permitted, allowing the computer process to perform the operation upon the resource, and when it is determined that the operation is not permitted, terminating the computer process.
  • a computer system comprising at least one computer readable medium storing metadata describing a plurality of capabilities, the plurality of capabilities including one or more capabilities associated with a first computer process executing on the computer system, and at least one processor configured to perform a method, the method comprising intercepting an operation to be performed by the first computer process upon a resource of the computer system, accessing the metadata describing the one or more capabilities associated with the first computer process, determining, based upon the metadata, whether the operation is permitted, when it is determined that the operation is permitted, allowing the first computer process to perform the operation upon the resource, and when it is determined that the operation is not permitted, terminating the first computer process.
  • At least one computer readable medium storing instructions that, when executed by at least one processor perform a method for enforcing security policies upon a computer process executing on a computer, the method comprising intercepting, by at least one processor of the computer system, an operation to be performed by the computer process upon a resource of the computer system, identifying, by the least one processor, one or more capabilities associated with the computer process, determining, by the at least one processor based upon the one or more capabilities, whether the operation is permitted, when it is determined that the operation is permitted, allowing the computer process to perform the operation upon the resource, and when it is determined that the operation is not permitted, terminating the computer process.
  • FIG. 1 is a block diagram illustrating enforcement of a security policy by a security policy manager, according to some embodiments
  • FIG. 2 is a block diagram depicting specification of capabilities for an illustrative script or script function, according to some embodiments
  • FIG. 3 is a block diagram depicting parameters used in executing a program in accordance with a set of capabilities, according to some embodiments
  • FIGs. 4A-4B illustrate examples of attempted operations within a file system, according to some embodiments
  • FIG. 5 is a flow chart of a method of enforcing a security policy, according to some embodiments.
  • FIG. 6 illustrates an example of a computing system environment on which aspects of the invention may be implemented.
  • Scripts and other executable processes that rely on ambient security can have potential effects that are both difficult to understand and difficult to control. For instance, it is not typically apparent from simply looking at a script what types of permissions might be needed for the script to execute successfully, because those permissions usually depend on operating system settings. Furthermore, the script's precise effects upon system resources are substantially left up to the operating system to determine, which means the operating system primarily controls the results of executing the script.
  • a script may be configured to receive a path to a directory as input and to perform operations that delete all files and directories in the specified directory.
  • the inventors have recognized and appreciated techniques for defining and enforcing security capabilities of scripts and/or other programs by developing an execution environment that can guarantee that execution of scripts and/or other programs will not lead to unintended or unforeseen consequences.
  • the execution environment determines whether to allow or prohibit operations based on a set of "capabilities" that are predetermined prior to initiating the operation.
  • a capability is a right to access a system resource, and may have associated privileges that detail the specific rights the capability grants with respect to the resource.
  • a capability may be defined for a file system directory and may be granted to a particular process executing on a computer system, thereby giving that process some access right to the directory.
  • a capability may be limited to particular privileges.
  • the above-described capability for the file system directory may include a privilege to lookup the contents of the directory yet not include a privilege to rename the directory.
  • Capabilities may be defined by a script, defined when executing a program, and/or may be defined by deriving capabilities from other capabilities. Examples of each of these techniques for defining capabilities are given in detail below. Irrespective of how the capabilities are defined, the execution environment can monitor execution of one or more processes to ensure that the processes comply with their associated capabilities. In this manner, the execution environment can ensure that the processes will not perform operations that exceed the access granted to them via their capabilities. Accordingly, suitable definitions of capabilities for processes executing in the execution environment will lead to predictable and controlled behavior.
  • a set of capabilities granted to a process may be altered during execution of the process, such as to add or remove capabilities granted to the process.
  • a process granted a capability to access a directory may perform a lookup operation to access a file stored within the directory. In some cases, this lookup operation may cause the capabilities granted to the process to be adjusted to add an additional capability to access the file.
  • the execution environment may provide a scripting language that allows users to perform conventional scripting operations, such as reading/writing files, executing programs or other scripts, and/or other operations on system resources, whilst providing tools for defining capabilities for various pieces of the script that can be guaranteed to be respected when the script is executed.
  • a function defined within a script might define the types of system resources that are to be passed as inputs or produced as outputs, along with capabilities that indicate the privileges (e.g., read access, write access, etc.) the function needs on those resources.
  • Such capability definitions can be interpreted as permissive - that is, no capabilities are assumed unless expressly granted by the script.
  • a user examining the script can see, from the script alone, what capabilities the function needs, which privileges are needed on those capabilities, and further has assurances that execution of the script will not exceed those granted capabilities.
  • a program executed by a script or otherwise can be executed within the execution environment with a set of capabilities that are defined at the time of execution.
  • the system may monitor one or more processes of the program and/or processes spawned by the program and ensure that each of these processes complies with their associated capabilities. Different processes of the program or different processes spawned by the same program may have different sets of capabilities, as discussed in further detail below.
  • FIG. 1 is a block diagram illustrating enforcement of a security policy by a security policy manager, according to some embodiments.
  • Illustrative execution environment 100 depicts a computer system executing a plurality of processes 110 and that contains a plurality of system resources 120.
  • a security policy manager 140 monitors operations performed by at least some of the processes 110 upon system resources 120 and determines, based on capabilities 130, whether or not to allow the relevant process to perform an operation.
  • the security policy manager 140 may be configured to intercept attempts to perform the operations rather than prohibit the initiation of an operation.
  • the security policy manager 140 when it is determined by security policy manager 140 that an operation attempted by a process is not allowed based on its granted capabilities, the security policy manager terminates the process. In some embodiments, when it is determined by security policy manager 140 that an operation attempted by a process is not allowed based on its granted capabilities, the security policy manager denies the operation but otherwise allows the process to continue. In such cases, the security policy manager may also output an error indicating that the operation was denied and may further provide diagnostic information about why the operation was denied.
  • Capabilities 130 are an illustrative set of capabilities granted to process 114 in the example of FIG. 1. In general, any number of the processes executing within the execution environment may have associated capabilities granted to them and the set 130 are shown merely as one example granted to an illustrative process.
  • Execution environment 100 may include processes within processes 110 that were initiated such that security policies will be enforced by security policy manager 140, and may also include processes within processes 110 that were not so initiated and will not be monitored for compliance with security policies. The latter group of processes are therefore executed without application of the techniques for enforcement of security policies described herein, whereas the former group are so executed.
  • a capability is a right to access a system resource, and may have associated privileges that detail the specific rights the capability grants with respect to the resource.
  • a capability could be merely a token indicating a particular system resource, thereby indicating that a process granted this capability has some kind of access granted to the resource.
  • a capability specifies one or more privileges upon a system resource. These privileges can then be given to a process by granting the corresponding capability to the process.
  • capabilities 130 and any associated privileges can be stored as metadata within execution environment 100, for example on a volatile storage medium (e.g., RAM), on a non-volatile storage medium (e.g., a hard disk), or on combinations thereof.
  • metadata describing capabilities may, in some embodiments, be attached to system resources for which the respective capabilities are granted.
  • Use cases in which capabilities are created or removed, including all instances of deriving capabilities as described below, may comprise editing metadata associated with those capabilities to update the description of which capabilities are granted, and with respect to which process(es) and system resource(s). For example, when a capability is granted to a process, the metadata may be edited to insert data describing this capability.
  • privileges for a file system resource may include read and/or write permissions, permission to view information about a file or directory, and/or lookup permission for a directory; privileges for a network resource may include permission to send and/or receive network data via a port and/or socket resource; privileges for a device resource may include permission to read data from the device, to operate one or more functions of the device, and/or to send data to the device; and privileges for a memory resource may include read and/or write permission to identifiable portions of memory, such as memory streams or pipes (e.g., read permission for standard out in a UNIX system).
  • certain capabilities may be expressly prohibited to avoid circumvention of the security policies. For instance, a capability to unload kernel modules may be prohibited from being granted to a process.
  • capabilities 130 may have been specified when process 114 began execution, thereby granting the process those capabilities.
  • a script may have been written to provide a function that specifies the capabilities used by the function, and process 114 may represent at least the portion of the script that includes the function executing in the execution environment 100.
  • an executable program may be executed whilst specifying the capabilities to be granted to the process that represents the executing program.
  • capabilities 130 may have been derived from another set of capabilities.
  • Derivation of capabilities for a process can include cases in which capabilities are inherited from another process and/or cases in which capabilities are inferred from other events. For example, when a process granted a set of capabilities spawns a sub-process, the sub-process may be granted (may inherit) the same set of capabilities to ensure that the sub-process does not exceed the capabilities granted to its parent process. As another example, a process that reads the contents of a directory may be granted an additional capability to read each file within the directory based on the results of the read operation.
  • capabilities 130 may include some combination of capabilities granted through specification (e.g., in a script function, when executing a program, etc.) and capabilities granted through derivation.
  • some operations on capabilities may cause additional capabilities to be granted.
  • a specification of which operations cause additional capabilities to be granted, and the types of those capabilities, can itself be granted as a privilege attached to a capability.
  • a process may be granted a capability for a directory wherein the capability includes a privilege to perform a lookup operation on the directory (to identify its contents).
  • This capability may also specify, via the same privilege or otherwise, that capabilities may be granted to results of a lookup operation on the directory (i.e., the contents of the directory), and may also specify privileges of those capabilities.
  • the capability may specify that each file identified in the directory as a result of a lookup operation on the directory is to be granted a capability with read privileges.
  • Such an approach may be beneficial in use cases where a capability is to be granted to a resource that can contain other resources, yet the other resources are not (or cannot) be identified when a process is initiated with the capability for the resource.
  • the process can be granted capabilities for the other resources at a time when they are not yet identified.
  • a set of capabilities can be stored and referenced using a string-based shortcut.
  • a shortcut is referred to herein as a "wallet” and may be, for example, a data structure that maps the string (e.g., as a key value) to one or more capabilities. This may provide a convenient way to refer to a set of capabilities (which in some cases may be a large set) by referring to the shortcut string instead of expressly listing the associated set of capabilities each time they are to be specified.
  • System resources 120 may include any resources utilized within an execution environment, such as file, network, device and/or memory resources.
  • types of system resources may include files, directories, file descriptors or handles, network sockets, locks, external devices, memory objects, memory streams, pipes, or combinations thereof.
  • any number and any types of system resources may be utilized by execution environment 100.
  • system resources amongst system resources 120 that are monitored by security policy manager 140 may have metadata attached to them so that the security policy manager can be notified (e.g., via a hook) before an operation on a respective resource is performed. The security policy manager can then determine whether to allow or deny the requested operation.
  • the security policy manager 140 determines, for an operation upon a system resource attempted by a process being monitored by the security policy manager, whether to allow or deny that operation based on the capabilities granted to the process. The decision to allow or deny an operation may also depend upon the type of operation and/or the type of system resource upon which the operation is to be performed. Processes managed by the security policy manager 140 therefore effectively operate in a restricted execution environment in that, unless all possible capabilities have been granted to the process, the process is restricted in some manner in the types of operations it can perform. Put another way, the allowable operations of the process is a subset of the set of all possible operations that the process could perform. Such a restricted execution environment is referred to herein as a "sandbox.” A process managed by the security policy manager can be said to be executed "within a sandbox,” meaning that it executes within a restricted execution environment.
  • some or all of the processes of processes 110 that are managed by security policy manager 140 may be associated with a session. Some processes may be associated with the same session. Processes in the same session can, in some use cases, share the same set of capabilities and can communicate with one another via signals. According to some embodiments, sessions, rather than processes, may be granted capabilities. Thus, each process executing within the same session can be guaranteed to have been granted the same set of capabilities.
  • sub-processes spawned by a process in a session are by default associated with the same session.
  • sessions can be hierarchical: a process that is part of one session can spawn a process inside a new session that has fewer capabilities than the first. This allows capability- aware executables to further attenuate their privileges.
  • sessions may be created manually by invoking a particular command, such as a system call. Such manual operations may create a session with no capabilities, but may also allow subsequent manual operations that grant capabilities to the session.
  • a decision by the security policy manager 140 to allow or deny an operation to be performed by a process may depend upon ambient security of the execution environment in addition to the capabilities granted to the process. This approach may be beneficial to ensure that capabilities granted to a process cannot be used to circumvent built-in security settings of the execution environment that would otherwise be respected in the absence of the security policy manager. For example, a file may be given read but not write permissions according to the operating system (at least for some users). While a process may be granted a capability that includes both read and write privileges upon the file, it may be beneficial to deny a write operation upon the file since the ambient permissions would not allow a write operation, even though the capability would have allowed it. Put another way, the security policy manager 140 may be configured to allow an operation only if the operation would be allowed both by capabilities granted to a process seeking to perform the operation and also by ambient authority of the process.
  • capabilities may be derived as a result of other operations and added or removed from a set of capabilities granted to a process.
  • the security policy manager 140 may be configured to determine, after an operation by a managed process upon a system resource completes, whether to derive capabilities for the process, and/or for other managed processes.
  • At least part of the security policy manager 140 may be supplied by the operating system of execution environment 100.
  • the operating system kernel may include some or all of the code for executing the security policy manager 140.
  • at least part of the security policy manager 140 may be supplied as an operating system module, such as a library or plug-in. In such cases, the module may interact with the operating system, including the kernel, to provide mechanisms for enforcing the security policy via the techniques described herein.
  • the security policy manager 140 may be configured to intercept operations that have already been initiated and to determine whether to allow the operation to complete or to prohibit the operation. Such an approach differs from one in which a computing system is configured to prohibit the mere initiation of an operation. For example, when executing an operation in a system that prohibits initiation of operations, the environment in which the operation is executed may examine the operation before determining whether to perform it or not. In contrast, a security policy manager 140 configured to intercept operations that have already been initiated may not have access to such an environment but would instead wait for the environment to initiate execution of the operation, then intercept the operation and determine whether to allow the operation to continue or to terminate the operation.
  • MAC Mandatory Access Control
  • the security policy manager 140 may be configured using Mandatory Access Control (MAC) techniques.
  • MAC Mandatory Access Control
  • access control decisions for all resources may be governed by a system-wide policy.
  • Examples of system- wide policies enforced by mandatory access control include so- called "multi-level security" and domain and type enforcement policies.
  • MAC techniques may provide controls allowing the security policy manager to monitor operations by managed processes and to take an action (e.g., allow or deny the operation, and/or terminate the process) based on associated capabilities to which it has access.
  • security policy manager 140 may log information about successfully performed operations and use this information to make decisions as to whether to allow or deny subsequent operations. Since security policy manager 140 may have a comparative low level view of system operations, it may not always be apparent from only the information the security policy manager obtains about a new operation, whether to allow or deny that operation. As such, the logged information can provide additional context to be utilized by the security policy manager in making such a decision.
  • a sub-process and/or new file handle resource may be created while the file is open. Subsequent attempts to write to the file with this sub-process and/or to write the file handle resource may not be permitted based on the capabilities granted to the process. Yet, in some cases, the security policy manager may receive only information that a process is attempting to write to a file or to a file handle. Without keeping track of why the file was opened and by which process (and, by extension, what the capabilities granted to the process were when it opened the file), the security policy manager may be unable to make an appropriate decision as to whether to allow or deny the write operation.
  • the security policy manager 140 may be configured to automatically manage sub-processes spawned by managed processes.
  • a process whose operations are managed by the security policy manager may spawn additional processes, and it may allow circumvention of the security policy if the security policy manager does not also manage those sub-processes, at least to some degree.
  • the security policy manager may be configured to identify when a managed process spawns a sub-process and to add the sub-process to the list of processes whose operations it is managing.
  • these separate capabilities may confer less privilege than a single capability with the combined privileges. For example, consider a pair of capabilities granted with respect to a network socket resource, wherein one has sufficient privileges to send but not receive messages at a particular port, and wherein the other has sufficient privileges to receive but not send messages on the same port. Because only a single socket can be bound to a port, a program with these capabilities must choose to either send or receive messages.
  • execution environment 100 may be configured such that when multiple capabilities are granted with respect to the same system resource, only one of the capabilities is retained. That is, capabilities are not combined or otherwise merged together.
  • Such a configuration may be native to the execution environment such that, for example, portions of the kernel (which, in some embodiments, may include at least part of the security policy manager 140)
  • the security policy manager 140 when attached to the kernel as an operating system module as described above, may take affirmative steps to prevent combination of capabilities.
  • the execution environment 100 may ensure (via code native to the kernel and/or via the security policy manager 140 acting as an operating system module) that a process is never granted conflicting privileges to the same object. For example, a process may be granted a capability for a directory with a privilege to create files in that directory that will subsequently have the read privilege. Subsequently, due to a lookup from the directory, the same process may be granted a capability with respect to the files in the directory with the write privilege. This second process might thereby suggest that two privileges for the process should be combined to grant the process a capability for the files with both the read and write privileges. However, execution environment 100 may be configured to prevent such merging, lest privileges become 'amplified' in an uncontrolled manner.
  • security policy manager 140 may be configured to output debugging information when it terminates a process after determining that an operation attempted by the process should be denied based on the process' granted capabilities. Such information may assist users in identifying at which point of execution and for what reason the process was terminated.
  • a function defined within a script may be defined so as to make clear the capabilities the script uses.
  • Such a definition thereby conveys the types of inputs the script or script function is willing to accept in terms of the valid types of input capabilities and, in some cases, the types of privileges these capabilities must have.
  • the definition also serves as a guarantee to a user executing the script or script function as to what types of operations the script will perform.
  • the definition of the capabilities may be viewed as a "contract" between the script or script function and a user executing the script or script function: the script or script function in effect promises not to exceed the stated capabilities so long as the input to the script or script function respects the defined input capabilities.
  • FIG. 2 shows a block diagram depicting a specification of capabilities for an illustrative script or script function, according to some embodiments.
  • a script or script function called "findjpgO" is defined to have input capabilities that can include capabilities 205 or 206, and has output capabilities 215. Note that the output capabilities need not be the identical to the output of the script; rather, the output capabilities define the privileges needed by the script during execution, which may include some or all of the output of the script, but need not.
  • findjpg() is an illustrative script or script function designed to search for files with the extension ".jpg". For simplicity, findjpg() will be described below as a "function,” yet it should be appreciated that findjpg() could equally be implemented as a script.
  • capability 205 is a directory capability that has associated privileges granting permission to: (i) list the contents of the directory; (ii) lookup contents of the directory; and (iii) obtain the path to the directory.
  • capability 206 is a file capability that has associated privileges granting permission to obtain the path to the file.
  • an input to the findjpg() function provides a capability that denotes either a directory or a file, which can be supplied much like a file descriptor is supplied in a conventional scripting language.
  • findjpg() is a file capability 215, for which a privilege is needed to append data to the file.
  • findjpg() produces output, at least in part, by writing the paths of files that it finds with extension ".jpg" to the file capability 215 by appending the data to the file.
  • # ifsrc is a file with extension jpg, output its path to out.
  • the contract specifies that, for the findjpg() function, the input "src" can be a directory ("dir") with the contents, lookup and path privileges, or can be a file with the path privilege.
  • the output "out” from the path is a file with the append privilege.
  • this contract indicates a post-condition of "void,” meaning that no value is returned from the function. While the findjpg() function is executing, its process(es) can be monitored (e.g., by security policy manager 140 in execution environment 100 shown in FIG. 1) and if any operations attempt to exceed what is allowed under this contract, the operation can be denied as described above.
  • the findjpg() function is indicated as having an input capability and an output capability
  • capabilities need not be expressly identified as such. That is, any capability may be considered to be an "input” and/or "output” in the sense that the capability may be associated with one or more operations of the function to read and/or write, and the syntax of the function need not expressly identify any capabilities as being input or output capabilities.
  • the function may simply utilize capabilities to perform operations, some of which may be write operations that can conceptually thought of as "outputs," and some of which may be read operations that can conceptually thought of as "inputs.”
  • a function or script may return a capability (or set of capabilities) as output to the function or script that invoked it. That is, the function or script may return one or more capabilities for future use by the invoking function or script, but such behavior is distinct from the capabilities needed for the function or script to perform its operations. That is, the function or script may write one or more capabilities as an output (e.g., to a file, to stdout, etc.) but such behavior is distinct from the capabilities needed for the function or script to perform its operations.
  • FIG. 3 is a block diagram depicting parameters used in executing a program, according to some embodiments.
  • program called "jpeginfo" is executed with a set of input capabilities in addition to a program argument.
  • jpeginfo is executed with a set of input capabilities in addition to a program argument.
  • a program such as a binary executable may be executed and input arguments may be passed in to the program.
  • a group of four capabilities are provided in addition to a program argument.
  • execution of a program may be performed in a restricted execution environment referred to as a "sandbox."
  • sandbox a restricted execution environment
  • parameter specified at the time of execution indicate the parameters of this sandbox - in particular, which capabilities the program has in its sandbox.
  • a program may be executed at a command line interface, within a script, from within another program, or via any other suitable method, as the techniques described herein are not limited to any particular technique for initiating execution of a program.
  • the "jpeginfo” program is designed to read a file that has a ".jpg” extension and provide some information about it.
  • capabilities provided to the program is a file capability with a read privilege.
  • capabilities to access standard out and standard error are specified, which are standard streams that are preconnected to the execution environment and that provide output and error streams, respectively. These capabilities have +append privileges so that the program can append data to those streams.
  • the "exec" command is configured to have two required arguments: the first, a file capability with the +exec privilege (the program being executed); and second, a list of string arguments to provide to the program being executed.
  • the path to the input file is provided as a capability, and standard out and standard error capabilities are also supplied.
  • the jpeginfo program will be executed in a sandbox to which the specified capabilities are granted.
  • FIGs. 4A-4B illustrate two examples of attempted operations within a file system, according to some embodiments.
  • the two examples of FIGs. 4A-4B also serve to illustrate how operations that act upon the current working directory (e.g., ".") or the parent of the current working directory (e.g., "..”) can be treated.
  • the inventors have recognized that propagating privileges in situations where a directory entry of ".” or is requested could lead to circumvention of the capabilities of a process.
  • Such a situation, in which privileges are prohibited from being "derived upwards" in a hierarchical file system directory structure will be further described below in relation to the examples of FIGs. 4A-4B.
  • privileges may be propagated upwards in a hierarchical file system directory structure by expressly allowing such behavior either as a general rule or by granting capabilities that have an associated privilege to perform upwards lookups in the directory structure.
  • FIG. 4A illustrates a file system having a root directory and, within the root directory, a directory named "home” that contains directories "alice” and "bob.”
  • a process is executing in the current working directory - the "bob" directory - labeled with "cwd” in the figure.
  • This process has been granted a capability with respect to the "bob” directory with a lookup privilege, and a capability with respect to the "alice” directory with a lookup privilege and a privilege to derive read privileges as a result of a lookup operation.
  • the privilege to derive read privileges is denoted by curly brackets ⁇ ⁇ to distinguish this privilege from a generic read privilege.
  • the executed process attempts to open a file “../alice/dog.jpg,” which would seek to open the "dog.jpg” file shown in the figure in the "alice” directory.
  • the process In order to locate this file, the process first needs to determine the value of which is the parent of the current working directory. Since the process has lookup privileges with respect to the current working directory, this operation is permitted and the process can resolve the directory to "/home.” However, the process must then look up the "alice” directory in "/home,” which is not permitted since the process does not have lookup privileges for the "/home” directory. This attempted lookup, which is not permitted, is illustrated by the large "X" in the figure.
  • FIG. 5 is a flow chart of a method of enforcing a security policy, according to some embodiments.
  • Method 500 may be performed by any suitable computing system, such as a computing system providing execution environment 100 shown in FIG. 1.
  • an operation to be performed upon a system resource of the computer system by a process is detected by the computing system.
  • detection may be performed by software executing on the computer system, including low-level software such as operating system and/or kernel routines, libraries and/or plug-ins.
  • Detection may, in some embodiments, be performed by a security policy manager as discussed above in relation to FIG. 1.
  • Detection of the operation in act 502 occurs after the process makes some attempt to perform the operation, yet before any aspect of the operation has completed, and in some use cases, before any aspect of the operation has begun.
  • the detection may therefore interrupt a typical sequence of events in which a process performs such an operation by intercepting or otherwise impeding the process from performing the operation as intended.
  • one mechanism to perform such detection is to use Mandatory Access Control (MAC) techniques, although any suitable mechanism may be used as embodiments of the invention are not limited in this respect.
  • MAC Mandatory Access Control
  • the computing system identifies capabilities associated with the process attempting to perform the operation.
  • a capability is a right to access a system resource, and may have associated privileges that detail the specific rights the capability grants with respect to the resource.
  • metadata stored within, or otherwise accessible by, the computing system indicates the metadata for the process attempting to perform the operation.
  • act 504 may comprise accessing such metadata and identifying stored capability information associated with the process.
  • the metadata may store process identifiers for processes executing on the computing system and may associate capability information with said identifiers. Identifying stored capability information may therefore comprise performing a lookup operation on the metadata using the process identifier as a key value.
  • the computing system determines whether the capabilities identified in act 504 permit the operation attempted by the process. If the capabilities do permit the operation, the process may be allowed to perform the operation in act 508. If the capabilities do not permit the operation, the process may be prohibited from performing the operation in act 510. In some embodiments, a process prohibited from performing an operation may be terminated by the computing system in act 510.
  • FIG. 6 illustrates an example of a suitable computing system environment 600 on which the technology described herein may be implemented.
  • computing system environment 600 may be used to define and/or enforce security policies upon computer processes as described herein (e.g., may be used to function as execution environment 100 in FIG. 1 and/or as the computing system performing method 500 shown in FIG. 5).
  • the computing system environment 600 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the technology described herein. Neither should the computing environment 600 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the illustrative operating environment 600.
  • computing systems, environments, and/or configurations that may be suitable for use with the technology described herein include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
  • the computing environment may execute computer-executable instructions, such as program modules.
  • program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types.
  • the technology described herein may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network.
  • program modules may be located in both local and remote computer storage media including memory storage devices.
  • an illustrative system for implementing the technology described herein includes a computing device in the form of a computer 610.
  • Components of computer 610 may include, but are not limited to, a processing unit 620, a system memory 630, and a system bus 621 that couples various system components including the system memory to the processing unit 620.
  • the system bus 621 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures.
  • such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus also known as Mezzanine bus.
  • ISA Industry Standard Architecture
  • MCA Micro Channel Architecture
  • EISA Enhanced ISA
  • VESA Video Electronics Standards Association
  • PCI Peripheral Component Interconnect
  • Computer 610 typically includes a variety of computer readable media.
  • Computer readable media can be any available media that can be accessed by computer 610 and includes both volatile and nonvolatile media, transitory and non-transitory media, removable and non-removable media.
  • Computer readable media may comprise computer storage media and/or communication media.
  • Computer storage media includes volatile and nonvolatile, removable and nonremovable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data.
  • Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by computer 610.
  • Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media.
  • modulated data signal means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal.
  • communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of the any of the above should also be included within the scope of computer readable media.
  • the system memory 630 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 631 and random access memory (RAM) 632.
  • ROM read only memory
  • RAM random access memory
  • BIOS basic input/output system
  • RAM 632 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 620.
  • FIG. 6 illustrates operating system 634, application programs 635, other program modules 636, and program data 637.
  • the computer 610 may also include other removable/non-removable, volatile/nonvolatile computer storage media.
  • FIG. 6 illustrates a hard disk drive 641 that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive 651 that reads from or writes to a removable, nonvolatile storage unit 652 (e.g., a flash memory drive having a Universal Serial Bus (USB) interface or other suitable interface), and an optical disk drive 655 that reads from or writes to a removable, nonvolatile optical disk 656 such as a CD ROM or other optical media.
  • USB Universal Serial Bus
  • removable/non-removable, volatile/nonvolatile computer storage media that can be used in the illustrative operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like.
  • the hard disk drive 641 is typically connected to the system bus 621 through a non-removable memory interface such as interface 640, and magnetic disk drive 651 and optical disk drive 655 are typically connected to the system bus 621 by a removable memory interface, such as interface 650.
  • the drives and their associated computer storage media discussed above and illustrated in FIG. 6, provide storage of computer readable instructions, data structures, program modules and other data for the computer 610.
  • hard disk drive 641 is illustrated as storing operating system 644, application programs 645, other program modules 646, and program data 647. Note that these components can either be the same as or different from operating system 634, application programs 635, other program modules 636, and program data 637.
  • Operating system 644, application programs 645, other program modules 646, and program data 647 are given different numbers here to illustrate that, at a minimum, they are different copies.
  • a user may enter commands and information into the computer 610 through input devices such as a keyboard 662 and pointing device 661, commonly referred to as a mouse, trackball or touch pad.
  • Other input devices may include a microphone, joystick, game pad, satellite dish, scanner, or the like.
  • These and other input devices are often connected to the processing unit 620 through a user input interface 660 that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB).
  • a monitor 691 or other type of display device is also connected to the system bus 621 via an interface, such as a video interface 690.
  • computers may also include other peripheral output devices such as speakers 697 and printer 696, which may be connected through an output peripheral interface 695.
  • the computer 610 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 680.
  • the remote computer 680 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 610, although only a memory storage device 681 has been illustrated in FIG. 6.
  • the logical connections depicted in FIG. 6 include a local area network (LAN) 671 and a wide area network (WAN) 673, but may also include other networks.
  • LAN local area network
  • WAN wide area network
  • Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.
  • the computer 610 When used in a LAN networking environment, the computer 610 is connected to the LAN 671 through a network interface or adapter 670. When used in a WAN networking environment, the computer 610 typically includes a modem 672 or other means for establishing communications over the WAN 673, such as the Internet.
  • the modem 672 which may be internal or external, may be connected to the system bus 621 via the user input interface 660, or other appropriate mechanism.
  • program modules depicted relative to the computer 610, or portions thereof may be stored in the remote memory storage device.
  • FIG. 6 illustrates remote application programs 685 as residing on memory device 681. It will be appreciated that the network connections shown are illustrative and other means of establishing a communications link between the computers may be used.
  • the invention may be embodied as a method, of which an example has been provided.
  • the acts performed as part of the method may be ordered in any suitable way. Accordingly, embodiments may be constructed in which acts are performed in an order different than illustrated, which may include performing some acts simultaneously, even though shown as sequential acts in illustrative embodiments.
  • actions are described as taken by a "user.” It should be appreciated that a "user” need not be a single individual, and that in some embodiments, actions attributable to a "user” may be performed by a team of individuals and/or an individual in combination with computer-assisted tools or other mechanisms.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Technology Law (AREA)
  • Multimedia (AREA)
  • Automation & Control Theory (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne, selon certains aspects, un procédé piloté par un processeur et visant à appliquer des politiques de sécurité à un processus informatique s'exécutant sur un ordinateur, le procédé comportant les étapes consistant à faire intercepter, par au moins un processeur du système informatique, une opération à effectuer par le processus informatique sur une ressource du système informatique, à faire identifier, par le ou les processeurs, une ou plusieurs fonctionnalités associées au processus informatique, à faire déterminer par le ou les processeurs, d'après la ou les fonctionnalités, si l'opération est autorisée, à permettre au processus informatique d'effectuer l'opération sur la ressource lorsqu'il est déterminé que l'opération est autorisée, et à mettre fin au processus informatique lorsqu'il est déterminé que l'opération n'est pas autorisée.
PCT/US2016/057703 2015-10-20 2016-10-19 Techniques pour définir et appliquer des politiques de sécurité à des processus informatiques et systèmes et procédés apparentés WO2017070209A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201562243900P 2015-10-20 2015-10-20
US62/243,900 2015-10-20

Publications (1)

Publication Number Publication Date
WO2017070209A1 true WO2017070209A1 (fr) 2017-04-27

Family

ID=58557782

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2016/057703 WO2017070209A1 (fr) 2015-10-20 2016-10-19 Techniques pour définir et appliquer des politiques de sécurité à des processus informatiques et systèmes et procédés apparentés

Country Status (1)

Country Link
WO (1) WO2017070209A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3550462A1 (fr) * 2018-04-03 2019-10-09 Palantir Technologies Inc. Système de sécurité et procédé de protection contre les codes malveillants

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030120935A1 (en) * 2001-12-20 2003-06-26 Coretrace Corporation Kernel-based network security infrastructure
US20060069692A1 (en) * 2004-09-28 2006-03-30 Exobox Technologies Corp Electronic computer system secured from unauthorized access to and manipulation of data
US20070101435A1 (en) * 2005-10-14 2007-05-03 Check Point Software Technologies, Inc. System and Methodology Providing Secure Workspace Environment
US20080120695A1 (en) * 2006-11-17 2008-05-22 Mcafee, Inc. Method and system for implementing mandatory file access control in native discretionary access control environments
US20130055341A1 (en) * 2006-08-04 2013-02-28 Apple Inc. Restriction of program process capabilities

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030120935A1 (en) * 2001-12-20 2003-06-26 Coretrace Corporation Kernel-based network security infrastructure
US20060069692A1 (en) * 2004-09-28 2006-03-30 Exobox Technologies Corp Electronic computer system secured from unauthorized access to and manipulation of data
US20070101435A1 (en) * 2005-10-14 2007-05-03 Check Point Software Technologies, Inc. System and Methodology Providing Secure Workspace Environment
US20130055341A1 (en) * 2006-08-04 2013-02-28 Apple Inc. Restriction of program process capabilities
US20080120695A1 (en) * 2006-11-17 2008-05-22 Mcafee, Inc. Method and system for implementing mandatory file access control in native discretionary access control environments

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3550462A1 (fr) * 2018-04-03 2019-10-09 Palantir Technologies Inc. Système de sécurité et procédé de protection contre les codes malveillants
US11301561B2 (en) 2018-04-03 2022-04-12 Palantir Technologies Inc. Security system and method

Similar Documents

Publication Publication Date Title
US7350204B2 (en) Policies for secure software execution
US7725922B2 (en) System and method for using sandboxes in a managed shell
JP4414092B2 (ja) 制限付きトークンを介した最小権限
US9594898B2 (en) Methods and systems for controlling access to resources and privileges per process
KR101278786B1 (ko) 클라이언트에 포함된 샌드박스형 코드에 의한 자원으로의액세스를 관리하기 위한, 컴퓨터 구현 방법, 시스템, 및이들을 구현하는 명령어가 저장된 컴퓨터 판독가능 매체
US7665143B2 (en) Creating secure process objects
Mayer et al. SELinux by example: using security enhanced Linux
Bélair et al. Leveraging kernel security mechanisms to improve container security: a survey
RU2584507C1 (ru) Способ обеспечения безопасного выполнения файла сценария
US11074323B2 (en) Method and system for persisting files
JP2006202290A (ja) オペレーティングシステムのプリミティブとしてのアプリケーションオブジェクト
Stefan et al. Flexible dynamic information flow control in the presence of exceptions
WO2017070209A1 (fr) Techniques pour définir et appliquer des politiques de sécurité à des processus informatiques et systèmes et procédés apparentés
US10616228B2 (en) Enhanced permissions for enabling re-purposing of resources while maintaining integrity
Shyamasundar et al. An experimental flow secure file system
Tidswell et al. An approach to dynamic domain and type enforcement
Ott The role compatibility security model
CN106886709B (zh) 一种文件加密中的应用程序动态授信方法
Schreuders et al. The functionality-based application confinement model
US11954203B2 (en) Methods and systems for identifying a compromised device through its unmanaged profile
Bijon Constraints for attribute based access control with application in cloud IaaS
WO2022183912A1 (fr) Procédé de contrôle d'accès obligatoire (mac) et dispositif associé
Ochilov Creating Secure File Systems in Open-Source Operating Systems
Salaün et al. StemJail: Dynamic Role Compartmentalization
Vermeulen SELinux System Administration

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16858132

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16858132

Country of ref document: EP

Kind code of ref document: A1