Metrology of files according to selection criteria based on file attributes

Abstract

The disclosure relates to metrology of files according to selection criteria based on file attributes. A technique includes registering a hook corresponding to a file event with a core of an operating system kernel, and associating the file event with an event-driven module of the operating system kernel. The core is associated with an integrity metric architecture policy. The techniques include triggering execution of an event-driven module in response to an occurrence of a file event to extend a range of integrity metric architecture policies. Executing the module includes: determining an attribute of a file associated with a file event by an operating system kernel; and filtering a set of rules of the extended integrity metric policy based on the attribute. Filtering includes identifying a given rule in the set of rules having a condition associated with the attribute depending on the file event. Executing the module includes the operating system kernel identifying an integrity measurement affiliated action for a given rule and performing the integrity measurement affiliated action on the file.

Description

Background Art

[0001] The computer platform may be subject to security attacks due to illegal attempts such as attackers trying to access information stored on the computer platform or attackers trying to damage the components of the computer platform. For purposes such as preventing security attacks, suppressing the extent of damage caused by any such security attacks, and instilling confidence that the computer platform can be trusted, the computer platform can have various security measures. For example, the computer platform can be protected by firewalls and other mechanisms that limit access to the computer platform based on password security parameters. As another example, the computer platform can have malware protection software that scans directories and searches for malware agents. As another example, the computer platform can have an integrity measurement architecture based on an operating system for measuring software components. These measurements may be useful for purposes such as identifying software components that have been damaged, preventing damaged executable files from being executed, and providing evidence that can be used to verify whether the computer platform is credible. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Figure 1 is a block diagram of a computer platform with an integrity measurement engine based on an operating system (OS) kernel extension according to an example implementation.

[0003] Figure 2 is an illustration of an extended integrity metric engine evaluating a file based on rules contained in an extended integrity metric policy according to an example implementation.

[0004] Figure 3 is a flow diagram depicting a process performed by an operating system kernel including an extended integrity measurement engine according to an example implementation.

[0005] Figure 4 is a flow chart depicting a process by an extended integrity metric engine for applying an extended integrity metric policy having namespace-based selection criteria, according to an example implementation.

[0006] Figure 5 is a flow diagram depicting an operating system-based technique for performing actions based on file attribute-based selection criteria in an integrity metric policy, according to an example implementation.

[0007] Figure 6 is an illustration of machine readable instructions that, when executed by a machine, cause an operating system kernel to selectively measure a file based on a namespace or file path associated with an event corresponding to the file in accordance with an example implementation.

[0008] Figure 7is a block diagram of a system including an operating system kernel core and an event-driven module according to an example implementation, wherein the operating system kernel core is used to measure a first file according to a first measurement strategy, and the event-driven module is used to selectively measure a second file based on an attribute of the second file. DETAILED DESCRIPTION

[0009] The following detailed description refers to the accompanying drawings. Whenever possible, the same reference numerals are used in the drawings and the following description to refer to the same or similar parts. However, it should be clearly understood that these drawings are for illustration and description purposes only. Although several examples are described in this document, modifications, adaptations and other implementations are possible. Therefore, the following detailed description does not limit the disclosed examples. On the contrary, the proper scope of the disclosed examples may be defined by the appended claims.

[0010] The terms used herein are only used for the purpose of describing specific examples, and are not intended to be restrictive. As used herein, the singular forms "one", "a kind of" and "said" are intended to also include plural forms, unless the context clearly indicates otherwise. As used herein, the term "multiple" is defined as two or more than two. As used herein, the term "another" is defined as at least the second or more. As used herein, the term "connection" is defined as directly connected without any intermediate element, or indirectly connected with at least one intermediate element, unless otherwise specified. Two elements can be mechanically coupled, electrically coupled, or linked by communication channels, paths, networks or system communications. As used herein, the term "and / or" refers to and covers any and all possible combinations of associated enumeration items. It will also be understood that although the terms first, second, third, etc. can be used to describe various elements in this article, these elements should not be limited to these terms, because these terms are only used to distinguish one element from another element, unless otherwise specified or the context indicates otherwise. As used herein, the term "includes" means including but not limited to, and the term "including" means including but not limited to. The term "based on" means at least partially based on.

[0011] The computer platform can perform integrity measurements on various software components during the startup of the platform and in the runtime environment of the platform. In this context, a "software component" (also referred to herein as a "component") refers to a referenceable data unit such as the content contained in a file, image, or logical volume. Integrity measurement can be used for any of a variety of different purposes. For example, the operating system kernel of the computer platform (referred to herein as the "kernel") can measure the executable file before the kernel loads and executes the executable file to ensure that the file is not damaged (for example, damaged due to damage or tampering). The kernel can, for example, compare the integrity measurement results of the executable file with the trusted reference integrity measurement results of the executable file, and if these integrity measurement results do not match, the kernel may not load and execute the executable file. As another example, a remote verifier can determine whether the computer platform can be trusted based on the authenticated summary of the integrity measurement results of the computer platform.

[0012] The kernel of a computer platform can measure a software component by applying a cryptographic hash function to the contents of the software component, thereby producing a hash value (or "hash") representing an integrity measurement result. Due to the nature of the cryptographic hash function, any minor change to the contents of the software component will cause the resulting hash value (integrity measurement result) to differ from a reference hash value (reference integrity measurement result). Therefore, this hash-based integrity measurement provides a highly reliable way to detect whether a software component has been altered and record evidence that can be used to assess whether the computer platform is trustworthy.

[0013] The computer platform may have a built-in integrity measurement architecture (IMA), and as part of the IMA architecture, the kernel may collect integrity measurement results of software components in the runtime environment of the computer platform. Here, the "runtime" environment refers to the state of the computer platform after startup when the control of the platform has been passed to the operating system. The IMA policy generally defines the criteria for which software components the control kernel measures. A specific IMA policy may have a set of statements or a set of rules, each of which defines an integrity measurement-related action (or "integrity measurement-affiliated action") and a condition for triggering this action. In an example, the measurement-related action may be an integrity measurement. In another example, the integrity measurement-related action may be an evaluation of the integrity measurement result. Existing IMA policies may have constraints (referred to herein as "IMA policy constraints") (such as constraints imposed by IMA policy syntax and / or semantics) that prevent IMA policy rules from specifically covering all files that may be considered important from the perspective of computer platform security or other perspectives. IMA policy constraints may result in the use of overly broad IMA policy rules that collect unnecessary integrity measurement results for the purpose of ensuring that certain important files are measured. Furthermore, IMA policy constraints may cause the scope of IMA policy rules to be too narrow and not cover the integrity measurement results of certain important files.

[0014] IMA policy constraints may prevent the implementation of policy rules that cover a specific non-executable file or a class of specific non-executable files. In this context, an "executable file" (also referred to herein as a "direct executable file") refers to a file that contains machine code (also referred to as "binary code") that can be executed directly by a hardware processor of a computer platform without further modification (e.g., without first applying compilation, interpretation, or further preprocessing to obtain the machine code). A direct executable file is a file that contains machine code, and the hardware processor executes the machine code, and in other words, the kernel can execute a direct executable file. In the context used herein, a "non-executable" file refers to a file other than a direct executable file.

[0015] There may be many reasons for verifying the integrity of a particular non-executable file or a particular class of non-executable files. For example, some non-executable files may be important to the state of a computer platform and may present a potential security attack surface. For example, the system configuration of a computer platform and the configuration of various applications and hardware devices of the computer platform may rely on configuration files that are non-executable files. An unintentional misconfiguration of the computer platform due to the configuration files containing incorrect configuration information, or an intentional misconfiguration of the computer platform due to the configuration files being corrupted due to tampering, may result in any of a number of adverse outcomes. As examples, these adverse outcomes may include the computer platform being exposed due to a security vulnerability, the computer platform being subject to a security attack, the computer platform having unacceptable system performance, the entire computer platform being shut down, the computer platform being isolated from a network, the computer platform being deemed untrustworthy, or certain computer platform functionality being unavailable.

[0016] An interpreted file is another example of a non-executable file that may be important to the state of a computer platform. In this context, an "interpreted" file refers to a file that contains content written in a programming language to be interpreted or converted by an interpreter. In other words, an interpreted file does not contain machine code that can be directly executed. In an example, the interpreter that processes the interpreted file may be a directly executable file. The interpreter, when executed, may convert the statements of the interpreted file line by line into machine code that is then executed. An interpreted file that is accidentally or intentionally corrupted may have a relatively large impact on the security of a computer platform, even if the interpreted file itself is not directly executed.

[0017] Some non-executable files may not affect the state of a computer platform, but verifying the integrity of these files may still be considered important. In an example, a build process on a computer platform may build a software product to be distributed. Integrity measurements may be beneficial for detecting tampering in the build process. For example, verifying the integrity of a downloaded file used in a build process may be important.

[0018] Within the IMA policy constraints, IMA policy rules that trigger integrity measurements of files in response to certain file events may be defined. As used herein, a "file event" refers to a kernel action involving a file. For example, a file event may be the execution of a file by the kernel, and the IMA policy rules may include an execution mask for the purpose of causing the kernel to collect integrity measurement results of the file to be executed by the kernel before the kernel loads and executes the file. As described above, the IMA policy constraints do not allow IMA policy rules that cover specific non-executable files or specific categories of non-executable files. Thus, for example, although the IMA policy may contain a rule with an execution mask that triggers measurements of an interpreter that is a direct execution file, due to the IMA policy constraints, the IMA policy rule may not be constructed to trigger measurements of specific interpreted files interpreted by the interpreter. Although the integrity measurement of the interpreter that processes the interpreted file can confirm or verify the integrity of the interpreter, the interpreted file may be compromised.

[0019] Policy rules covering measurements of specific volumes (e.g., logical volumes) may be defined within IMA policy constraints. Thus, one approach for building an IMA policy covering measurements for certain non-executable files may involve building one or more rules in the IMA policy for measuring certain volumes containing non-executable files. However, this approach results in a single integrity measurement for each volume. A single integrity measurement may be associated with a large amount of measurement "noise." In this way, even minor changes to components of a volume (e.g., updating, deleting, or adding relatively unimportant files or images) may change the integrity measurement results for the volume and may cause the integrity measurement results to differ from the expected reference integrity measurement results for the volume. Therefore, although some components of a volume may be considered unimportant (in terms of platform security or other reasons), any (multiple) changes to these components may cause the volume to fail integrity verification.

[0020] Another approach to constructing an IMA policy that covers integrity measurement of certain non-executable files may involve including rules in the IMA policy that cover specific file events that may occur for all files. For example, an IMA policy rule may contain a read mask for the purpose of triggering integrity measurement of all files to be read by the kernel. In another example, a rule may contain a write mask for the purpose of triggering integrity measurement of all files to be written by the kernel. However, due to the relative non-selectivity of such a rule, such a rule may place a significant burden on the integrity measurement architecture of a computer platform.

[0021] According to example embodiments described herein, an operating system kernel has an extended integrity metric architecture controlled by a policy (referred to herein as an "extended integrity metric policy") that allows rules for overriding integrity metrics for specific non-executable files. According to example embodiments, for the purpose of selecting a file or a class of files for an integrity metric-related action, the extended integrity metric policy may include rules that specify at least one of a file attribute-based selection criterion or a context-based selection criterion. As an example, for the purpose of selecting a specific file or a class of specific files, the file attribute-based selection criterion may specify a specific file attribute such as a specific file name (also referred to as a "file name"), a file name pattern, a file modification date, a file type, or another file attribute. In an example, the file attribute-based selection criterion may include a comparison operator (e.g., an equality operator, a less than operator, a greater than operator, or other comparison operator) and a file attribute reference (e.g., a reference file creation date), such that if the file attribute satisfies the comparison (e.g., the file creation date is more recent than the reference file creation date), the criterion is satisfied. In another example, the file attribute-based selection criterion may specify a regular expression (or "regex") that identifies a file name pattern, such that if the file name has the file name pattern, the criterion is satisfied. In an example, the context-based selection criterion may be a file path. In another example, the context-based selection criteria may be a particular namespace associated with the entity requesting access to the file. In an example, the context-based selection criteria may specify a context associated with the file event (e.g., a certain namespace, a full file path, or a partial file path) such that the criteria is satisfied if the file event is associated with the specified context (e.g., the requestor accessing the file is associated with the specified namespace, or the file is stored in a location corresponding to a particular file path). For conditions that include multiple context-based selection criteria, whether the condition of the rule is satisfied may depend on the result of a logical combination of the criteria.

[0022] One or more file attribute-based selection criteria establish a condition for a rule that, if satisfied for a particular file, results in an integrity metric-related action being performed on the file (the action also specified by the rule). For a condition that includes multiple file attribute-based selection criteria, whether the condition of the rule is satisfied may depend on the result of a logical combination of the criteria. In an example, for a condition with multiple file attribute-based selection criteria, the condition may be satisfied if all of the criteria of the condition are satisfied (e.g., a logical AND of the criteria produces a Boolean true result). In another example, for a condition with multiple file attribute-based selection criteria, the condition may be satisfied if one of the criteria is satisfied (e.g., a logical OR of the criteria produces a Boolean true result). In an example, whether a condition with multiple file attribute-based selection criteria is satisfied may depend on a relatively more complex logical expression than a single AND operator or OR operator. As an example, the metric-related action may be an integrity metric or an evaluation.

[0023] A specific rule of the extended integrity metric policy may contain a condition including zero, one or more selection criteria based on file attributes, and the condition may include zero, one or more selection criteria based on context. For a condition including multiple selection criteria (e.g., a selection criterion based on file attributes and a selection criterion based on context), whether the condition is satisfied may depend on the result of a logical combination of the criteria.

[0024] As a more specific example, a rule for selecting a specific configuration file or a class of specific configuration files may include a condition specifying the selection of files having a ".cfg" file extension (a selection criterion based on file attributes) and a file creation date on or after a certain date (a selection criterion based on file attributes) for measuring the related action. In another example, a rule for selecting a specific interpretation file or a class of specific interpretation files may include a condition specifying the selection of files having a ".py" PYTHON file extension (a selection criterion based on file attributes), a file creation date after a certain date (a selection criterion based on file attributes) and stored at a location corresponding to a specific file path (a selection criterion based on context) for measuring the related action.

[0025] In the context used herein, "file attribute" refers to an attribute or characteristic of a file. In an example, the file attribute may be a file name, and "file attribute-based selection criteria" refers to a specific characteristic or a class of specific characteristics of a file. The file attribute-based selection criteria may, for example, identify a specific file by its full file name. In another example, the file attribute-based selection criteria may identify a specific portion or pattern of a file name (e.g., a specific file extension or a specific pattern of alphanumeric characters that appear in the main file name) for the purpose of identifying a specific group or class of files having a file name portion with a pattern. In an example, the file attribute-based selection criteria may be in the form of a specific regular expression (or "regex") or a numeric comparison.

[0026] In another example, the rules of the extended integrity measurement policy may include selection criteria based on file attributes in addition to criteria based on file name. In an example, the selection criteria based on file attributes may be specific file permissions such as execute permissions. This may be particularly advantageous for incorporating certain files into the integrity measurement scope. Although a non-executable file may have execute permissions, traditional IMA policy constraints do not allow rules to specifically cover this file because this file is not directly executable, and therefore, simply including an execute mask in the IMA policy rule will not cover this file. However, in the case of an extended integrity measurement policy, a rule may, for example, specify that any file with execute permissions that covers a non-executable file with execute permissions is to be measured. In an example, the rules of the extended integrity measurement policy may specify that measurement-related actions are performed on any file with a specific full or partial file name (e.g., the file extension ".sh" for a shell script file as a target) and execute permissions.

[0027] In another example, the selection criteria based on file attributes can be a specific file type (e.g., a specific LINUX file type). As other examples, the selection criteria based on file attributes can be a file creation date, a file modification date, or a file last access date. In an example, for the purpose of selecting a class of files to be added to a computer platform after a certain date, the selection criteria based on file attributes can select a file creation date after a certain reference date. In another example, the selection criteria based on file attributes can be a specific file size. For example, for the purpose of selecting a class of files greater than a specific size to measure, the selection criteria based on file attributes can be a digital comparison for selecting a file size greater than a specified minimum size.

[0028] As used herein, "context" refers to an attribute or characteristic of an environment associated with a file event, and "context-based selection criteria" refers to a specific characteristic or a class of specific characteristics of the environment of a file event. In an example, the context-based selection criteria may be a specific file path or a class of specific file paths that store the files to be measured. As an example, the context-based selection criteria may define a specific file path and may or may not include subpaths of this specific file path. As another example, the context-based selection criteria may be a namespace (e.g., a process namespace or a user namespace) associated with the requestor of the file event (e.g., a host or a container).

[0029] As a more specific example, Figure 1 A computer platform 100 is depicted according to an example implementation. According to many possible implementations, the computer platform 100 may have one of many different potential architectures. Regardless of its specific architecture, a "computer platform" in the context used herein is a processor-based electronic device having an operating system that includes an integrity measurement architecture. As an example, the computer platform may be a standalone server, a rack-mounted server module; an edge processing rack-mounted module; a blade server; a blade enclosure containing one or more blade servers; a client; a thin client; a desktop computer; a portable computer; a laptop computer; a notebook computer; a tablet computer; a network device, a network switch, a gateway device, a smart phone; a wearable computer; or other platform.

[0030] The computer platform 100 may include one or more hardware processors 110 (e.g., one or more central processing units (CPUs), one or more CPU processing cores, one or more graphics processing units (GPUs), one or more GPU processing cores, and other hardware processors); and system memory 140. The system memory 140 and other memories discussed herein are non-transitory storage media that may be formed by semiconductor memory devices, memristor-based memory devices, magnetic memory devices, phase change memory devices, combinations of devices of one or more of these memory technologies, and the like. The system memory 140 may represent a collection of memories of both volatile memory devices and non-volatile memory devices.

[0031] System memory 140 includes user space and kernel space. Kernel space represents the location of system memory 140 for storing machine-readable instructions, data, and data structures corresponding to operating system kernel 112 (also referred to herein as "kernel 112"). User space represents the location of system memory 140 used by non-operating system kernel processes or user processes, such as processes corresponding to execution instances of application 111, virtual machine instances, container instances, and other processes.

[0032] The system memory 140 may store machine-readable instructions 141 that are executed by the processors 110 to form various components of the computer platform 100. In an example, during a runtime environment of the computer platform 100, one or more processors 110 may execute instructions 141 associated with the kernel 112. In another example, during a runtime environment, one or more processors 110 may execute instructions 141 associated with the application 111. In another example, during a runtime environment, one or more processors 110 may execute instructions 141 associated with a Unified Extensible Interface (UEFI) runtime service.

[0033] like Figure 1 As depicted, according to an example implementation, kernel 112 includes core 114. In an example, core 114 may be a compiled operating system kernel, and according to a further example, core 114 may be part of a commercially available operating system package. In an example, core 114 may include any or some combination of the following: a LINUX operating system, a MICROSOFT WINDOWS operating system, a MAC operating system, a FREEBSD operating system, or other operating systems.

[0034] The core 114 can perform various operations on the file 132 in conjunction with the file event, use and / or use this file. As used herein, a "file" refers to a container of information. In an example, the file 132 can be associated with a file system as a method and data structure for organizing a collection of files. In an example, the file 132 in the file system can be organized using a directory as a hierarchical structure or tree; and the location of the file within the file system can be identified by a corresponding file path. In an example, the file system can be a physical file system in which the file conforms to a specific data storage format. In another example, the file system can be a virtual file system, which can be an upper file system layer of a composite file system, and the composite file system includes a lower physical file system accessed through the virtual file system. In an example, the computer platform 100 can have a root file system, which contains files for starting the computer platform 100, and other file systems can be installed at mount points corresponding to subdirectories of the root file system.

[0035] like Figure 1 As depicted in the example implementation of , files 132 may be stored in one or more storage devices 130 (e.g., mass storage devices, persistent memory, storage arrays, or other storage devices) of computer platform 100. However, a given file 132 may be stored in a variety of other locations. In an example, a given file 132 may be stored in whole or in part in system memory 140. In another example, a given file 132 may be stored in a memory of a hardware device of computer platform 100. In another example, a given file 132 may be stored in a network attached storage device.

[0036] In an example, a file event may be an operating system operation for accessing a file 132. In this context, "accessing" a file may refer to reading content from a file 132, writing content to a file 132, executing a file 132, or linking a file to another directory location. In an example, a file event may be a response of the core 114 to a system call to read, write, execute, or link a particular file 132. In another example, a file event may be an operating system operation in which the core 114 responds to a system call to memory map a file 132. In another example, a file event may be an operating system operation that occurs as part of the core's execution of a particular file 132.

[0037] System calls for initiating file events can be issued by execution entities such as applications 111 and interpreters 150 (which are specific types of applications 111 discussed herein). Applications 111 can be executed as part of a host of a computer platform 100, and applications 111 can be executed within an application operating environment 156 in the computer platform 100. In this context, "host" refers to an environment associated with an unabstracted view of the system resources of the computer platform 100 (e.g., system memory 140, processor, and operating system 112). "Application operating environment" refers to a domain in which applications executing in the domain have an abstracted view of system resources. A given application 111 can be a monolithic application, or it can be a non-monolithic application decomposed into a collection of microservices.

[0038] An example of an application operating environment 156 is a container. Typically, a container is a virtual runtime environment for one or more applications and / or application modules, and this virtual runtime environment is constructed to interface with the kernel 112. For example, a container for a given application may contain the executable code of the application and its dependencies, such as system tools, libraries, configuration files, executable files, and binary files of the application. The container includes an operating system kernel mount interface, but does not include an operating system kernel. Thus, for example, the computer platform 100 may include multiple containers that share the kernel 112 through corresponding operating system kernel mount interfaces. Docker containers and rkt containers are examples of containers. The computer platform 100 may include a container manager (not shown) that performs actions for setting up containers, also referred to as a container engine daemon. Typically, a container engine daemon may perform actions for building and running containers. According to an example embodiment, one or more virtual machines may reside in a given container, and one or more applications may be executed in a given virtual container. In another example, the application operating environment 156 may be a container group (pod) of containers. For example, the application operating environment 156 may be a container group of containers associated with a particular microservice.

[0039] A given file 132 contains data that can represent any of a variety of different content or information. For example, an executable file 132 can store directly executed machine code (or "binary code"). As a specific example, an executable file 132 can contain content that is directly executed to form an interpreter 150. The interpreter 150 contains machine code that is directly executed by (multiple) processors 110, also referred to herein as being directly executed by the core 114 (or directly executed by the kernel 112). In an example, the interpreter 150 can process the interpretation file 132 line by line, and this processing includes converting one or more commands of the line into machine code that can then be executed by the processor 110. In another example, the executable file 132 can store machine code that, when executed, forms an application 111 other than the interpreter 150.

[0040] In an example, executable file 132 may have an identifying file extension (e.g., an ".exe" extension), although other executable files 132 may not have an extension or an extension that identifies the executable nature of file 132. In another example, executable file 132 may have associated metadata that identifies file 132 as an executable file (e.g., metadata stored in an index node (or "inode") associated with file 132). In another example, executable file 132 may be stored in a specific location associated with executable files (e.g., in a " / bin" directory folder). In another example, executable file 132 may have content that identifies file 132 as directly executable.

[0041] A given file 132 may be an interpretation file. In this context, an "interpretation file" refers to a file containing code written in a programming language and converted to machine code by an interpreter. As an example, an interpretation file 132 may be a PYTHON file, a hypertext preprocessor file (or "PHP" file), a JAVASCRIPT file, a Ruby file, a shell script file, or other files containing code interpreted or converted to machine code for direct execution by an appropriate interpreter. In another example, an interpretation file 132 may have a file extension (e.g., a ".py" extension) that associates the file 132 with a specific interpreter 150 (e.g., a PYTHON interpreter 150). In another example, an interpretation file 132 may have a primary file name that associates the file 132 with a specific interpreter 150. In another example, an interpretation file 132 may have content that identifies the file 132 as an interpretation file. In another example, an interpretation file 132 may be stored in a specific location (e.g., a subfolder of a folder containing a corresponding interpreter 150) that identifies the file as an interpretation file 132.

[0042] In another example, the specific file 132 may be a configuration file. In this context, a "configuration file" refers to a file that controls the settings and / or operation of one or more components of the computer platform 100. In an example, the component may be an application 111, and the configuration file 132 may contain data that controls the features and / or settings of the application 111. In another example, the component may be a hardware component (e.g., an expansion card or a network interface), and the configuration file 132 may contain data that controls the installation and / or settings of the hardware component. In other examples, the configuration file 132 may contain data that controls the installation and / or settings of the entire computer system, a specific subsystem, a utility program, or a process. In an example, the configuration file 132 may have an identifying file extension (e.g., a ".cfg" extension). In another example, the configuration file 132 may have associated metadata (e.g., metadata stored in an index node associated with the file 132), which identifies the file 132 as a configuration file and / or associates the file as being associated with a specific application 111, a process, or a utility program. In another example, the configuration file 132 may have associated content that identifies the file 132 as a configuration file and / or associates the file as being associated with a particular application 111, process, or utility. In another example, the configuration file 132 may be stored in a specific location associated with the configuration file (e.g., a " / etc" folder).

[0043] Other files 132 may be non-executable files that are not interpreted or configured files. In an example, files 132 may store text content, financial data, application processing result data, audio data, audio-visual data, database records, video data, spreadsheet data, or data representing other content. In addition, a given non-executable file 132 may or may not affect the state of computer platform 100, and a given non-executable file 132 may or may not be important to the security of computer platform 100.

[0044] According to an example embodiment, the core 114 includes components of IMA, including an IMA metric evaluation engine 115, an integrity measurement engine 180, and an evaluation engine 184. In an example, the IMA metric evaluation engine 115 can determine whether certain software components of the computer platform 100 should be measured based on the IMA policy 113. The IMA policy 113 contains statements or rules that define the scope of certain integrity measurement-related actions (e.g., measurements and / or evaluations) of software components of the computer platform 100. In an example, a specific rule of the IMA policy 113 can contain an execution mask and specify an action. The execution mask causes the IMA metric evaluation engine 115 to perform a specified action on all system calls pointing to a direct executable file. In this way, the rule causes the IMA metric evaluation engine 115 to perform a specified action on the file 132 in response to the kernel 112 receiving a system call to execute a specific file 132 before the file 132 is loaded into memory and executed.

[0045] In an example, the specified action may be an integrity measurement action, and the IMA metric evaluation engine 115 may initiate an integrity measurement of the file 132 by the integrity measurement engine 180 before the file 132 is loaded into memory and executed by the core 114. Another rule of the IMA policy 113 may specify an execution mask and an evaluation action. An "evaluation action" (or "evaluation") refers to an operation that compares an integrity measurement result with a reference integrity measurement result and controls whether the file 132 can be executed based on the comparison result.

[0046] According to an example implementation, the integrity measurement result is a hash. In the context used herein, a "hash" (which may also be referred to as a "hash," "hash value," "hash digest," "cryptographic hash," or "cryptographic hash value") is produced by applying a cryptographic hash function to a value (e.g., an input such as the contents of file 132). A "cryptographic hash function" may be a function provided by a processor (e.g., by one or more hardware processors 110 provided to execute instructions as part of the metric engine 180) executing machine-executable instructions.

[0047] A cryptographic hash function can receive an input, and the cryptographic hash function can then generate a hexadecimal string to match the input. For example, the input can include a data string (e.g., a data structure in a memory represented by a starting memory address and an ending memory address). In this example, the cryptographic hash function outputs a hexadecimal string based on the data string. Further, any slight change in the input may change the hexadecimal string of the output. In another example, the cryptographic hash function can be a secure hash function (SHA), any hash function approved by the Federal Information Processing Standard (FIPS), any hash function approved by the National Institute of Standards and Technology (NIST), or any other cryptographic hash function. In some examples, instead of the hexadecimal format, the string can use another format.

[0048] Constraints imposed on the IMA policy 113 (e.g., syntactic and / or semantic constraints) may not allow the rules of the IMA policy 113 to cover the measurement-related actions of a particular non-executable file 132. However, certain non-executable files 132 (e.g., configuration files and interpreted files) may be important to the security of the computer platform 100. Constructing rules with broad scope within the constraints imposed on the IMA policy 113 (e.g., a rule that triggers measurement of all files within a volume or a rule that triggers measurement of all reads and / or writes) may overburden the IMA architecture and / or generate considerable measurement noise. In addition, for commercially provided cores 114, modifying the core 114 to remove constraints or at least change constraints to allow specific non-executable files 132 to be covered by the IMA policy 113 may invalidate the guarantee of covering the core 114.

[0049] According to an example embodiment, the IMA policy scope is extended to cover specific non-executable files 132 via the inclusion of an extended integrity metric assessment engine 118 within the kernel 112. According to an example embodiment, the extended integrity metric assessment engine 118 is separate from the core 114, and the extended integrity metric assessment engine 118 is controlled by an extended integrity metric policy 119. Unlike the IMA policy 113, the extended integrity metric policy 119 may contain one or more rules that trigger metric-related actions (e.g., measurements and evaluations) for specific non-executable files 132.

[0050] The extended integrity measurement policy 119 allows a rule to cover any specific non-executable file 132 or any specific class of non-executable files 132. In an example, the non-executable file 132 or class of non-executable files covered by a specific rule of the extended integrity measurement policy 119 may be important to the state of the computer platform 100. In an example, a rule of the extended integrity measurement policy 119 may cover a certain interpreted file or a certain class of interpreted files. In an example, a rule of the extended integrity measurement policy 119 may cover a certain configuration file or a certain class of configuration files. In another example, the non-executable file 132 or a certain class of non-executable files covered by a specific rule of the extended integrity measurement policy 119 may not affect the state of the computer platform 100 and / or may not affect the security of the computer platform 100. For example, a rule of the extended integrity measurement policy 119 may cover a certain file or a certain class of files downloaded as part of a build process for building a distributed software product on the computer platform 100.

[0051] According to some embodiments, kernel 112 may be a LINUX kernel, and extended integrity metric assessment engine 118 may be added to kernel 112 as an eBPF module. An eBPF module is a program that is external to a compiled LINUX kernel (e.g., kernel 114) and runs in a sandbox in a privileged context within a LINUX kernel (e.g., kernel 112). Although originally, the acronym "eBPF" referred to "extended Berkeley Packet Filter", the term "eBPF" is an independent term that covers privileged contexts and sandboxed programs in addition to programs that perform packet filtering.

[0052] According to an example embodiment, for the purpose of selecting a file or a class of files for a metric-related action based on a file attribute characteristic (e.g., a file name, a file extension, a file name pattern, a file type, a file permission, a file modification date, a file creation date, a file size, or other file attribute characteristic), the extended integrity metric policy 119 may include a given rule that defines a file attribute-based selection criterion. According to an example embodiment, for the purpose of specifying a particular context characteristic (e.g., a namespace associated with an entity requesting access to a file or a file path of the file), a rule of the extended integrity metric policy 119 may include a context-based selection criterion. In general, a given rule of the extended integrity metric policy 119 may include zero, one, or more file attribute-based selection criteria, and the given rule may include zero, one, or more context-based selection criteria. The one / more file attribute-based selection criteria (if any) and the one / more context-based selection criteria (if any) of a given rule of the extended integrity metric policy 119 together define a condition of the rule, such that if the condition is satisfied for a particular file, the metric-related action specified by the rule is performed.

[0053] According to an example embodiment, the metric engine 180 collects integrity metrics (as controlled by the engines 115 and 118 and the policies 113 and 119), and for the collected integrity metrics, stores entries representing and recording the integrity metrics in kernel space structures in the system memory 140. For example, the entry may contain information such as a hash value corresponding to the integrity metric of the file, the file name of the file, and a hash value corresponding to the entire entry. In addition, according to an example embodiment, the entry may identify a specific location in the secure memory 166 (e.g., a specific platform configuration register (PCR)) where a metric digest corresponding to the metric is stored.

[0054] According to some embodiments, secure memory 166 may be a set of PCRs for secure processor 163. According to an example embodiment, the IMA architecture of computer platform 100 may perform a series of measurements during a measured boot of computer platform 100 to establish a trust chain for computer platform 100. The root of the trust chain may be, for example, a hardware boot block that measures and loads an initial firmware set. The initial firmware set may then be executed, and as part of this execution, the initial firmware set measures and loads the next firmware set. Based on the measured boot, the construction of the trust chain continues, with each component measuring the next component to be loaded and executed. The measurement results collected during the measured boot may be used to build a summary of the measurement results. For example, the PCRs of secure processor 163 may be extended by the measurements performed during the measured boot to create a summary of the measurement results corresponding to the trust chain.

[0055] As part of the reporting trust root (RTR), the security processor 163 may also be able to send authenticated measurement result information to a requesting device (such as a remote verifier 194) for the purpose of attestation. In an example, the measurement result information may include a summary of the measurement results stored in the secure memory 166 of the security processor 160. Generally, attestation refers to a process in which an electronic device (such as a remote verifier 194) referred to as a "verifier" determines whether another electronic device (such as a computer platform 100) is trustworthy. In an example, the remote verifier 194 may initiate attestation by challenging the computer platform 100 via an attestation request. In another example, the computer platform 100 may initiate attestation without prior contact or questioning from the remote verifier 194. Regardless of how the attestation is initiated, as part of the attestation, the security processor 163 may send an authenticated summary of the measurement results to the remote verifier 194. In this context, "authenticated summary" refers to a set of measurement results of the computer platform 100 signed by the security processor 163. A TPM reference (also referred to as a "PCR reference," which contains PCR values) is an example of an authenticated digest, although the authenticated digest may take other forms according to further embodiments.

[0056] According to an example embodiment, the extended integrity metric evaluation engine 118 can be used to further extend the trust chain obtained by the measured launch of the computer platform into the user space. In this way, according to an example embodiment, the measurement result summary that is constructed as part of the integrity measurement results collected as part of the measured launch of the computer platform 100 and the IMA policy 113 can be extended with the integrity measurement results (e.g., the integrity measurement results of the interpretation file and the configuration file) that are collected due to the extended integrity measurement policy 119. According to an example embodiment, the IMA metric evaluation engine 115 can measure and evaluate the module 116 before the event-driven module 116 is loaded and executed. Therefore, the integrity measurement of the event-driven module 116 extends the measurement result summary, and the integrity measurement results collected due to the execution of the module 116 are used to extend the measurement result summary.

[0057] According to an example embodiment, the core 114 calls the event-driven module 116 (and thus instantiates an instance of the extended integrity metric assessment engine 118) in response to certain hooks (e.g., LINUX Security Module (LSM) hooks). According to an example embodiment, a "hook" refers to a mechanism of the core 114 that allows program code external to the core 114 (such as the event-driven module 116) to execute in response to a certain event. For the purpose of triggering the execution of the event-driven module 116, the hook can be registered with the core 114. In this context, registering a specific hook (such as a hook corresponding to a file event) with the core 114 generally refers to associating the execution of a machine-executable instruction (e.g., the event-driven module 116) with a specific event (e.g., a file event) so that when the event occurs, control of the operating system 112 is transferred to the machine-executable instruction, so that the machine-executable instruction can be executed before control returns to the core 114. According to an example embodiment, the event-driven module 116 is hooked into certain file events so that when one of these file events occurs, the event-driven module 116 is executed.

[0058] As a specific example, according to some embodiments, for a LINUX operating system, whenever a file 132 is accessed (read, written, executed, or linked), a file_open hook (and more specifically, a lsm.s / file_open hook) can be used to initiate execution of the event-driven module 116. As another example, the hook can initiate execution of the event-driven module 116 in response to a specific program execution operation. As another example, the hook can initiate execution of the event-driven module 116 in response to a file memory mapping operation.

[0059] As used herein, an "engine" may refer to one or more circuits. For example, a circuit may be a hardware processing circuit that may include any one or some combination of a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit (e.g., a programmable logic device (PLD), such as a complex PLD (CPLD)), a programmable gate array (e.g., a field programmable gate array (FPGA)), an application specific integrated circuit (ASIC), or other hardware processing circuits. An "engine" may refer to a combination of one or more hardware processing circuits and machine-readable instructions (software and / or firmware) that may be executed on the one or more hardware processing circuits. According to some embodiments, the extended integrity metric assessment engine 118 may be formed by one or more processors 110 that execute machine-readable instructions associated with the event-driven module 116.

[0060] Among other features, according to example embodiments, the computer platform 100 may include one or more input / output (I / O) bridges 120 that allow communication between the processor 110 and the security processor 163, as well as communication with a plurality of storage devices 130; a video controller; a baseboard management controller (BMC) 160; and possibly other devices. More specifically, according to some embodiments, the bridge(s) 120 may include a north bridge that includes a memory controller (for system memory 140 access) and a peripheral component interconnect express (PCIe) root port. In addition, the bridge(s) 120 may include a south bridge that provides I / O ports, such as a serial advanced technology attachment (SATA) port, a universal serial bus (USB port), a low pin count (LPC) port, a serial peripheral interface (SPI) port, an extended SPI (eSPI) port, and the like. According to some embodiments, the north bridge may be part of the processor 110. According to further embodiments, the north bridge and the south bridge may be combined into a single bridge 120; and according to some embodiments, this single bridge 120 may be part of the processor 110. According to some embodiments, bridge(s) 120 provide communications with one or more intelligent I / O peripherals (not shown) of computer platform 100 via one or more buses (eg, a PCIe bus, a Compute Express Link (CXL) bus, or other communications links).

[0061] In addition to executing machine-readable instructions for providing an operating system kernel 112, the processor(s) 110 may execute instructions for providing firmware runtime services, such as UEFI runtime services 109 for a runtime environment of the computer platform, and for providing firmware boot services, such as UEFI boot services and a basic input / output system (BIOS), during booting of the computer platform 100. The processor(s) 110 may also execute instructions for providing one or more application instances 111, one or more interpreter 150 instances, and various other processes, such as container daemons, hypervisors, container instances, container groups, and virtual machine instances, for the computer platform 100.

[0062] According to an example implementation, the computer platform 100 may have one or more network interface controllers (NICs) 121 for communicating with a remote validator 194 via a network fabric 190. The network fabric 190 may be associated with one or more types of communication networks such as, by way of example, a Fibre Channel network, a CXL fabric, a dedicated management network, a local area network (LAN), a wide area network (WAN), a global network (e.g., the Internet), a wireless network, or any combination thereof.

[0063] According to some embodiments, the security processor 163 may be in the form of a chip that resides on the computer platform 100, separate from the main processor 110. According to an example embodiment, the security processor 163 may be an integrated circuit built into the motherboard of the computer platform 100. According to some embodiments, the security processor 163 may be a virtual device (e.g., a virtual TPM).

[0064] BMC 160 can provide various management services for computer platform 100, such as monitoring sensors (e.g., temperature sensors, cooling fan speed sensors); monitoring operating system status; monitoring power status; logging computer platform 100 events; providing remote control management functions for computer platform 100; and the like.

[0065] According to some embodiments, BMC 160 can provide a security plane isolated from its management plane. Using its security plane, BMC 160 can provide various security services for computer platform 100 (e.g., secure storage for cryptographic security parameters, cryptographic services, cryptographic key sealing and unsealing, and other security services). According to some embodiments, BMC 160 can include a silicon trust root engine corresponding to the hardware root of the trust chain of computer platform 100. According to some embodiments, the silicon trust root engine can measure, load and execute the initial security service related firmware of BMC 160 in response to power-on or reset of computer platform 100 to start the startup of measurement. According to some embodiments, BMC 160 (rather than a security processor) can store and sign the measurement result summary of computer platform 100, and BMC 160 can provide the authenticated measurement result summary of computer platform 100 to remote verifier 194.

[0066] As used herein, a "baseboard management controller" or "BMC" is a dedicated service processor that uses sensors to monitor the physical state of a server or other hardware and communicates with a management system through a management network. The baseboard management controller can communicate with applications executing at the operating system level through the following: an input / output controller (IOCTL) interface driver, a representational state transfer (REST) ​​application program interface (API), or some system software agent that facilitates communication between the baseboard management controller and the application. The baseboard management controller can perform hardware-level access to hardware devices located in a server chassis including system memory. The baseboard management controller can be able to directly modify hardware devices. The baseboard management controller can operate independently of the operating system of the computer platform 100. The baseboard management controller can be located on a motherboard or main circuit board of a server or other device to be monitored.

[0067] The fact that a baseboard management controller is installed on a motherboard of a managed server / hardware or is otherwise connected or attached to the managed server / hardware does not prevent the baseboard management controller from being considered "separate" from the server / hardware. As used herein, a baseboard management controller has management capabilities for subsystems of a computing device and is separate from the processing resources that execute the operating system of the computing device. Thus, as an example, the baseboard management controller of the computer platform 100 is separate from the processor(s) 110 that execute the high-level operating system for the computer platform 100.

[0068] Figure 2A diagram 200 is depicted of an extended integrity metric engine evaluating a file 132 according to an extended integrity metric policy 119 according to an example implementation. For the following examples, assume that the file 132 is a non-executable file, i.e., a file 132 that is not directly executed. It should be noted that according to a non-extended IMA policy, the kernel core (rather than the extended integrity metric evaluation engine 118) may perform integrity metric-related actions on the executable file.

[0069] refer to Figure 2 , the evaluation of the file 132 by the extended integrity metric evaluation engine occurs in response to a particular file event 204 associated with the file 132. In an example, the file event 204 may correspond to a system call for accessing the file 132 (e.g., a system call for reading from, writing to, executing, or linking to the file 132). In other examples, the file event 204 may be a system call for memory mapping the file 132. The file event 204 may correspond to a particular kernel hook such that the extended integrity metric evaluation engine 118 is invoked in response to the file event 204 before the kernel performs a corresponding action (e.g., read, write, execute, or link) corresponding to the file event 204.

[0070] like Figure 2 As depicted, file 132 may be associated with one or more file attributes 212. As an example of file attributes 212, file 132 may have a file name (or "file name"). For example, a file name may be a series of alphanumeric characters. A file name may or may not have an extension (e.g., .cfg, .exe, etc.).

[0071] In another example, the file attributes 212 may be permissions associated with the file 132. In an example, the permissions may be read permissions (e.g., whether the file 132 may be read), write permissions (e.g., whether the file 132 may be written or modified), or execute permissions (e.g., whether the file 132 may be executed). Figure 2 For example, assume that file 132 is a non-executable file, however, file 132 may have execution permissions that allow execution of file 132. For example, file 132 may be an interpreted file that can be indirectly executed by an interpreter.

[0072] According to an example implementation, file permissions may be described by metadata stored in an index node corresponding to file 132. The metadata may describe other file attributes 212, such as, for example, a modification date, a last access date, creation data, file size, or other attributes of file 132.

[0073] The metadata may further describe another attribute 212 of the file 132 - the file type. For example, in the case of the LINUX 6 operating system, a file may have one of seven different file types: regular file, directory file, link file, character special file, block special file, socket file, or named pipe.

[0074] The file attributes 212 form part of a set of input characteristics 230 that the extended integrity metric evaluation engine 118 may consider when determining whether the file 132 falls within the scope of the extended integrity metric policy 119. In addition to the file attributes 212, according to an example embodiment, the extended integrity metric evaluation engine 118 may consider other input characteristics 230 corresponding to the context 216 associated with the file event 204. Figure 2 As depicted, such context-dependent input characteristics 230 may include a namespace (eg, a process namespace associated with the caller, a user namespace associated with the caller, or a mount space associated with the caller) and a file path of the storage file 132 .

[0075] In response to a file event 204 corresponding to a particular file 132, the extended integrity metric evaluation engine 118 filters the rules 280 of the extended integrity metric policy 119 based on the corresponding input characteristics 230 for the purpose of determining whether the file 132 is within the scope of the extended integrity metric policy 119. In this context, "filtering" of the rules 280 generally refers to evaluating the rules 280 for the purpose of determining whether any of the rules 280 are applicable to the file 132. If one or more of the rules 280 are determined to be applicable, then the file 132 is within the scope of the extended integrity metric policy 119. In an example, filtering may include the extended integrity metric evaluation engine 118 traversing and evaluating each rule 280 based on the one or more input characteristics 230 for the purpose of determining whether the rule 280 is applicable to the file 132. In another example, filtering may include the extended integrity metric evaluation engine 118 applying a more targeted approach, wherein a category or categories of rules 280 are first identified based on the one or more input characteristics 230, and then the extended integrity metric evaluation engine 118 searches for rules 280 within the category(s). In another example, filtering may include the extended integrity metric evaluation engine 118 identifying specific file attributes associated with the file 132, identifying any specific rules 280 that include the file attributes as criteria, and then evaluating the logical expression(s) of the identified rule(s) 280. In another example, filtering may include the extended integrity metric evaluation engine 118 identifying specific contexts associated with the file event 204, identifying any specific rules 280 that include the contexts as criteria, and then evaluating the logical expression(s) of the identified rule(s) 280. Regardless of how filtering is performed, if one or more rules 280 are within the scope of the extended integrity metric policy 119, the extended integrity metric evaluation engine 118 initiates the appropriate metric-related action(s) 284 set forth by the applicable rule(s) 280, and control of the processing of the file event 204 is then returned to the kernel core. Otherwise, if the extended integrity metric evaluation engine 118 determines that the file 132 is outside the scope of the extended integrity metric policy 119 , the extended integrity metric evaluation engine 118 returns control to the kernel core without the engine 118 initiating any integrity metric-related actions for the file 132 .

[0076] like Figure 2As depicted, for example rule 280-1, rule 280-1 includes a trigger condition 288 (or "condition 288") associated (as depicted at 285) with an integrity metric-related action 284 (or "action 284"). Condition 288 identifies one or more criteria that control whether condition 288 is satisfied and, therefore, whether the extended integrity metric evaluation engine 118 initiates action 284. In other words, rule 280-1 has condition 288 that is dependent on file event 204 being associated with one or more specific criteria.

[0077] In the example, Figure 2 As depicted, a particular rule 280, such as example rule 280-1, may include a file attribute-based selection criterion 292 and a context-based selection criterion 294. Thus, based on the logical combination of the file attribute-based selection criterion 292 and the context-based selection criterion 294, if the input characteristic 230 satisfies the condition 288, the extended integrity metric engine 118 initiates the associated metric-related action 284.

[0078] In an example, a given rule 280 may include a condition 288 that specifies a single file attribute-based criterion 292 and does not specify a context-based selection criterion 294. In another example, a given rule 280 may include a condition 288 that specifies a single context-based criterion 294 and does not specify a file attribute-based selection criterion 292. In another example, a given rule 280 may include a condition 288 that specifies multiple file attribute-based criteria 292. In another example, a given rule 280 may include a condition 288 that specifies multiple context-based criteria 294. In another example, a given rule 280 may include a condition 280 that specifies multiple file attribute-based criteria 292 and multiple context-based criteria 294.

[0079] Regardless of the one or more specific criteria included in the rule 280, according to an example embodiment, the extended integrity metric evaluation engine 118 initiates an action 284 specified by the rule 280 in response to meeting or satisfying the condition 288 of the rule 280. According to an example embodiment, meeting or satisfying the condition 288 of the rule 280 means that the input characteristic 230 matches all one or more criteria of the condition 288.

[0080] According to an example implementation, more than one rule 280 of the extended integrity metric policy 119 may apply to a given file 132. For example, multiple rules 280 of the extended integrity metric policy 119 may specify metric-related actions 284 for the same file 132. In a more specific example, one rule 280 may trigger measurement of non-executable files 132, and another rule 280 may trigger evaluation of non-executable files 132. As another example, multiple rules 280 of the extended integrity metric policy 119 may collectively set a scope for certain files 132. For example, one rule 280 may set forth a condition 288 that covers a certain group or class of non-executable files 132, and this rule 280 may specify that files 132 belonging to the class are to be measured. Continuing with the example, another rule 280 may set forth a condition 288 that covers a narrower subset of the class, and specify that files 132 belonging to the subset are not to be measured (i.e., here, the action 284 is an action that is not to be performed). Taking these two rules into account, for this example, the extended integrity metric evaluation engine 118 initiates measurement of files 132 that are within the class and that are not in the subset of the class.

[0081] In an example, a specific rule 280 of the extended integrity metric strategy 119 has a condition 288 defined by a logical AND of the criteria of the condition 288, such that if the file 132 and / or the associated context of the file event satisfies the criteria, then the condition 288 is satisfied. According to further embodiments, whether the condition 288 is satisfied may be more logically complex. In this way, according to some embodiments, the condition 288 may specify a combinatorial logical expression (e.g., an expression containing one or more logical operators such as AND, OR, XOR, and NOT) for combining the criteria, such that if the combined expression produces a certain result (e.g., a Boolean true result), then the condition 288 is satisfied.

[0082] Figure 2 An exemplary process 250 is depicted that may be performed by the extended integrity metric evaluation engine 118 in response to a particular file event 204. In an example, the process 250 may be called in response to a file hook of an event-driven module (e.g., an eBPF module) of the kernel transferring control, and the process 250 may be performed by machine-readable instructions of the executing module. According to decision block 254 of the process 250, the extended integrity metric evaluation engine 118 determines whether there are any applicable plurality of rules 280 applicable to the file event 204. In other words, according to the process 250, the extended integrity metric evaluation engine 118 determines whether the input feature 230 satisfies the condition(s) 288 of one or more rules 280.

[0083] If no applicable rule 280 applies to the input feature 230, the extended integrity metric assessment engine 118 returns control to the kernel core and the process terminates. Otherwise, if one or more rules 280 are applicable, the extended integrity metric assessment engine 118 may initiate one or more metric-related actions associated with the applicable rule(s) 280, as depicted at 256. More specifically, as depicted at decision block 258, the extended integrity metric assessment engine 118 determines whether to initiate measurement of the file 132. If so, the extended integrity metric assessment engine 118 initiates measurement of the file 132 (block 262) and logging (block 266), which may be performed by the kernel's integrity metric engine. For example, logging may involve the kernel storing entries in kernel space representing the metric and information about the metric, and the logging may further include a kernel extension metric result summary.

[0084] The extended integrity metric evaluation engine 118 may also determine (decision block 270) whether to perform an evaluation. For example, one rule 280 may specify a metric for the file 132 and another rule 280 may specify an evaluation. If an evaluation is not to be performed, the process 250 terminates and control returns to the kernel's core. Otherwise, according to block 274, the extended integrity metric evaluation engine 118 initiates an evaluation by the kernel's evaluation engine and control returns to the kernel core.

[0085] Figure 3 A technique 300 is depicted performed by an operating system kernel in response to a file event according to an example implementation. The operating system kernel may have an IMA component built into a compiled kernel core and an extended integrity measurement architecture corresponding to a kernel-based event-driven module (e.g., an eBPF module). Figure 3 , technology 300 can be triggered by a file event hook. In an example, the file event hook can be a hook corresponding to a file access event involving reading, writing, executing or linking. In another example, the file event hook can correspond to a memory mapping operation or can correspond to an execution operation. In an example, the hook can be a LINUX security module hook.

[0086] According to block 304, technique 300 includes transferring control to an extended integrity metric assessment engine disposed by the operating system kernel in response to the file event hook. According to an example implementation, the kernel instantiates an instance of the integrity metric assessment engine as a result of the file event and the corresponding file event hook. The extended integrity metric assessment engine may then determine whether to apply any one or more rules of the extended integrity metric policy according to decision block 308. This determination may involve the extended integrity metric assessment engine evaluating input characteristics (e.g., file attribute characteristics, namespace, file path) associated with the file and / or file event using criteria (e.g., file attribute-based criteria and context-based criteria) of the rules of the extended integrity metric policy to see if any rule conditions are met. Rules may be constructed to target certain files based on file attribute-based criteria and / or context-based criteria. According to an example implementation, rules may target specific interpreted files and / or specific categories of non-executable files, such as interpreted files, configuration files, or other non-executable files.

[0087] If the extended integrity metric assessment engine determines to apply one or more rules, according to decision block 308, the extended integrity metric assessment engine applies the action(s) of the rule(s), according to block 312. In an example, the actions may include actions for measuring, evaluating, not measuring, and not evaluating.

[0088] like Figure 3 As depicted, after the above-described processing transfer due to the file event hook, control returns to the kernel core according to block 314. Then, according to decision block 318, the kernel core may determine whether any IMA policy rules apply, and if so, according to block 322, execute the metric-related actions of the rule(s).

[0089] Figure 4 An exemplary technique 400 for selecting and applying rules for an extended integrity metric policy based on a namespace associated with a file event is depicted in accordance with an example implementation. Figure 4 Technique 400 includes determining (decision block 404) whether the event is associated with a host namespace or a container namespace. Figure 4 As depicted, if the event is associated with a host namespace, a determination is made as to whether there are one or more applicable rules for the host namespace, per decision block 416. If so, then as per block 420, the appropriate action associated with the rule(s) is initiated.

[0090] According to decision block 404, if it is determined that the event is associated with a container namespace, then according to decision block 408, it may be determined whether there are one or more applicable rules for the container namespace. According to some implementations, for example, files accessed in the container namespace may not be measured. According to decision block 408, if one or more applicable rules are identified, control passes to block 412 where the associated action(s) are initiated.

[0091] Technique 400 may be particularly advantageous for covering integrity measurement-related actions for files that can be accessed by both the host and the container. If a volume is mounted on the host and is intended to be used by a container, the volume or any file therein may be intentionally excluded from the scope of a traditional namespace-unaware IMA policy due to the way IMA measurement results are logged. In this way, when a file is accessed in the context of a container, the measurement results of the file will be added to the IMA log on the host, with its path relative to the path of the container. The host may then fail the proof due to a mismatch between the path and / or measurement results and the host's reference path and / or reference measurement results. One way to prevent this from happening in a namespace-unaware IMA policy is to exclude the volume from integrity measurement. However, this approach may allow an attacker to access the volume and execute files without being measured by IMA. As depicted in technique 400, due to the namespace awareness of the extended integrity measurement policy, the namespace associated with the requester can be considered as part of the determination of whether to measure the file.

[0092] Thus, for example, a namespace-aware rule of an extended integrity measurement policy may be constructed to trigger measurement of a file of a volume mounted into a container if the file is accessed by the host, but not trigger measurement of the same file if the file is accessed by the container. In this way, integrity measurements are taken of the files of the volume and logged in a manner that allows verification of the integrity measurement results.

[0093] According to further embodiments, namespace-aware rules of an extended metrics policy may trigger metrics-related actions (e.g., measurements or evaluations) for certain files (e.g., files of a particular volume) accessed by a particular container, but not trigger any metrics-related actions for the same files when they are accessed by the host. This may be beneficial, for example, when logging metrics results using container file path references.

[0094] refer to Figure 5According to an example embodiment, the technique 500 includes registering (block 504) a hook corresponding to a file event with a core of an operating system kernel, and associating the file event with an event-driven module of the operating system kernel other than the core. The core is associated with an integrity measurement architecture policy. The file event may be associated with a file. According to an example embodiment, the file may be a non-executable file. In an example, the non-executable file may be a configuration file. In another example, the non-executable file may be an interpreted file.

[0095] According to example implementations, the file event can be a file access event, such as an event corresponding to a system call that reads from a file, writes to a file, links a file, or executes a file. In another example, the file event can be an event corresponding to a system call that is used to memory map a file. In an example, the operating system can be a LINUX operating system, and the hook can be a LINUX security module (LSM) hook.

[0096] According to an example implementation, technique 500 includes triggering (block 508) execution of an event-driven module in response to occurrence of a file event to extend the scope of an integrity metric architecture policy. Executing the event-driven module includes determining, by an operating system kernel, an attribute of a file associated with the file event ("file attribute"), and filtering a rule set of an extended integrity metric policy based on the attribute. The filtering includes identifying a given rule in the rule set, the given rule having a condition that depends on the file event being associated with the attribute. Executing the event-driven module includes identifying an integrity metric ancillary action for the given rule and performing the integrity metric ancillary action on the file. In an example, the file attribute may be a file name. In an example, the file attribute may be a file name pattern, such as a combination of alphanumeric characters present in a file name or file extension. In an example, the file attribute may be a modification date, a creation date, or an access date of the file. In an example, the file attribute may be represented by metadata stored in an index node corresponding to the file. In an example, the file attribute may be a file type. In an example, the file attribute may be a permission associated with the file (e.g., read, write, or execute permission). In an example, the file attribute may be a size of the file. In an example, filtering the rule set may include evaluating a logical expression contained in a rule.

[0097] In an example, the metric-affiliated action may be an action for measuring a file. In another example, the metric-affiliated action may be an action for evaluating a file. In another example, the metric-affiliated action may be an instruction to not perform a particular action (e.g., not perform an evaluation).

[0098] refer to Figure 6According to an example embodiment, the non-transitory storage medium 600 stores machine-readable instructions 604. The instructions 604, when executed by the machine, cause the machine to cause the operating system kernel to determine, in response to an event associated with a file, whether the file is within the scope of the integrity measurement policy based on at least one of a namespace associated with the event or a file path associated with the event. In an example, the event may be a file access event. In an example, the file access event may be an event of reading from, writing to, or executing a file.

[0099] In an example, the namespace may be a process namespace. In an example, the namespace may be a mount namespace. In an example, the namespace may be a user namespace.

[0100] In an example, determining whether a file is within the scope of the integrity measurement policy includes evaluating a rule set forth in the integrity measurement policy. According to an example implementation, causing an operating system kernel to determine whether a file is within the scope of the integrity measurement policy includes hooking into a kernel core. In an example, a LINUX Security Module (LSM) hook may be used. In an example, determining whether a file is within the scope of the integrity measurement policy includes determining whether a namespace associated with an event is a criterion of a rule of the integrity measurement policy. In an example, determining whether a file is within the scope of the integrity measurement policy includes determining whether a file path associated with an event is a criterion set forth in a rule of the integrity measurement policy.

[0101] In an example, the machine-readable instructions may be instructions associated with an event-driven module of an operating system kernel. In an example, the machine-readable instructions may be instructions of an eBPF module.

[0102] Instructions 604, when executed by the machine, further cause the machine to cause the operating system kernel to selectively measure the file in response to determining whether the file is within the range. In an example, measuring the file may include applying a hash function to the contents of the file to provide a corresponding hash value. According to an example implementation, the instructions may cause the machine to evaluate the file. In an example, evaluating the file may include comparing the measurement results of the file with a trusted reference measurement result of the file. According to an example implementation, selectively measuring the file includes not measuring the file.

[0103] refer to Figure 7 According to an example implementation, system 700 includes memory 704 and processor 715. Memory 704 includes instructions 708. Processor 715 executes instructions 708 to cause a core of an operating system kernel to measure the first file according to a first measurement policy in response to a corresponding action for executing the first file.

[0104] In an example, the instructions for causing the core to measure the first file include instructions corresponding to an integrity measurement architecture (IMA) of the core. According to an example implementation, the instructions for causing the core to measure the first file are responsive to an action of executing the first file. In an example, the first file may include a directly executable file.

[0105] Processor 715 further executes instruction 708 to cause an event-driven module of the operating system kernel that is separated from the core to determine the attribute of the second file in response to a second event associated with the second file. In an example, the attribute can be the file name of the file. In an example, the attribute can be a mode associated with the file name of the file. In an example, the attribute can be an attribute identified by metadata associated with the file. In an example, the attribute can be the file type of the file. In an example, the attribute can be the size of the file. In an example, the attribute can be the modification date of the file. In an example, the attribute can be the permissions of the file.

[0106] In an example, the second file may be a file that is not directly executed by the processor. In an example, the second file may be an interpreted file executed by an interpreter. In an example, the interpreter may be directly executed by the processor. In an example, the second file may be a configuration file.

[0107] Processor 715 further executes instruction 708 to determine whether to measure the second file based on the attribute and the second measurement strategy. Determining whether to measure the second file can be based on the attribute of the second file, the namespace associated with the event, or the file path associated with the event. Determining whether to measure the second file may include determining whether a condition of a rule of the second measurement strategy is applied to the attribute of the second file.

[0108] The processor 715 further executes the instruction 708 to selectively measure the second file based on the result of the determination of whether to measure the second file. In an example, the determination may include the processor identifying a rule that identifies an attribute as satisfying a criterion of the rule, and the rule may be associated with the measurement action. According to some embodiments, the event-driven module may be a module executed in a sandbox of a privileged kernel. In an example, the event-driven module may be an eBPF module.

[0109] According to an example implementation, the attribute is execution permission. Identifying a given rule includes determining that the file has execution permission. A particular advantage is that the integrity metric can be extended to include specific non-executable files.

[0110] According to an example embodiment, the attribute comprises a file type, and identifying a given rule comprises determining that a condition specifies a file type characteristic corresponding to said file type. A particular advantage is that the integrity metric may be extended to include certain non-executable files.

[0111] According to an example embodiment, the attribute comprises a file name, and identifying a given rule comprises determining that a condition specifies a file name characteristic corresponding to the file name. A particular advantage is that the integrity metric can be extended to include specific non-executable files.

[0112] According to an example embodiment, the attribute comprises a file creation date, and identifying a given rule comprises determining that the condition specifies a file creation date characteristic corresponding to said file creation date. A particular advantage is that the integrity metric may be extended to include certain non-executable files.

[0113] According to an example implementation, a file event may be associated with a context. Identifying a given rule includes determining that a condition specifies a context characteristic corresponding to the context. A particular advantage is that the integrity metric may be extended to include specific non-executable files.

[0114] According to an example embodiment, the context includes a namespace, and identifying a given rule further includes determining that the condition specifies a namespace property corresponding to the namespace. A particular advantage is that the integrity metric can be extended to include specific non-executable files.

[0115] According to an example embodiment, the context includes a file path, and identifying a given rule further includes determining that the condition specifies a file path characteristic corresponding to the file path. A particular advantage is that the integrity metric can be extended to include certain non-executable files.

[0116] According to an example embodiment, the file comprises a configuration file or an interpretation file. A particular advantage is that the integrity metric can be extended to include certain non-executable files.

[0117] According to an example embodiment, the event driven module includes machine executable instructions that run in a privileged context and within a sandbox. A particular advantage is that the integrity metric can be extended to include specific non-executable files.

[0118] While the present disclosure has been described with respect to a limited number of embodiments, numerous modifications and variations of the present disclosure will become apparent to those skilled in the art having the benefit of this disclosure. The appended claims are intended to cover all such modifications and variations.

Claims

1. A method comprising: registering a hook corresponding to a file event with a core of an operating system kernel, and associating the file event with an event-driven module of the operating system kernel other than the core, wherein the core is associated with an integrity measurement architecture policy; and In response to the occurrence of the file event, the execution of the event-driven module is triggered to extend the scope of the integrity measurement architecture policy, wherein the execution of the module includes the operating system kernel performing the following operations: determining attributes of a file associated with the file event; filtering a rule set of an extended integrity metric policy based on the attribute, wherein the filtering comprises identifying a given rule in the rule set, the given rule having a condition dependent on the file event being associated with the attribute; identifying an integrity metric-attached action for the given rule; and The integrity metric-affiliated action is performed on the file.

2. The method of claim 1, wherein: The file has execute permission, and identifying the given rule includes determining that the condition is dependent on the file having the execute permission.

3. The method of claim 1, wherein: The attribute comprises a file type, and identifying the given rule comprises determining that the condition specifies a file type characteristic corresponding to the file type.

4. The method of claim 1, wherein: The attribute includes a file name, and identifying the given rule includes determining that the condition specifies a file name characteristic corresponding to the file name.

5. The method of claim 1, wherein: The attribute includes a file creation date, and identifying the given rule includes determining that the condition specifies a file creation date characteristic corresponding to the file creation date.

6. The method of claim 1, wherein: The file event is associated with a context; and Identifying the given rule includes determining that the condition specifies a contextual characteristic corresponding to the context.

7. The method of claim 6, wherein: The context includes a namespace, and identifying the given rule further includes determining that the condition specifies a namespace property corresponding to the namespace.

8. The method of claim 6, wherein: The context includes a file path, and identifying the given rule further includes determining that the condition specifies a file path characteristic corresponding to the file path.

9. The method of claim 1, wherein: The files include configuration files or interpretation files.

10. The method of claim 1, wherein: The event driven module includes machine executable instructions that run in a privileged context and within a sandbox.

11. A non-transitory machine-readable storage medium storing machine-readable instructions, which, when executed by a machine, cause the machine to perform the following operations: causing the operating system kernel to determine, in response to an event corresponding to a file, whether the file is within the scope of an integrity measurement policy based on at least one of a namespace associated with the event or a file path associated with the event; and The operating system kernel is caused to selectively measure the file in response to the determining whether the file is within the range.

12. The storage medium according to claim 11, wherein: The instructions, when executed by the machine, further cause the machine, in response to determining that the file is within the range, to apply a hash function to contents of the file to determine a hash value representing a metric of the file.

13. The storage medium of claim 11, wherein: The first namespace is associated with a host of the machine, and the second namespace is associated with a container running on the host; The integrity measurement policy associates a measurement action with the first namespace; and The instructions, when executed by the machine, further cause the operating system kernel to measure the file in response to determining that the namespace associated with the event corresponds to the first namespace.

14. The storage medium of claim 11, wherein: The first namespace is associated with a host of the machine, and the second namespace is associated with a container running on the host; and The instructions, when executed by the machine, further cause the operating system kernel to bypass measuring the file in response to determining that the namespace associated with the event corresponds to the second namespace.

15. The storage medium according to claim 11, wherein: The instructions, when executed by the machine, further cause the operating system kernel to determine whether the file is within the scope of the integrity measurement policy based on selection criteria based on file attributes.

16. The storage medium according to claim 15, wherein: The selection criteria based on file attributes include file type characteristics, file permission characteristics, file name characteristics or file modification date characteristics.

17. A system comprising: A memory, the memory being used to store instructions; as well as A processor, the processor being configured to execute the instructions to perform the following operations: causing a core of the operating system kernel to measure the first file according to a first measurement policy in response to a corresponding action for executing the first file; and The event-driven module of the operating system kernel separated from the core is caused to perform the following operations: determining an attribute of a second file in response to a file event associated with the second file; determining whether to measure the second file based on the attribute and the second measurement strategy; as well as The second file is selectively measured based on a result of the determination as to whether to measure the second file.

18. The system of claim 17, wherein: The second file includes a configuration file or an interpretation file.

19. The system of claim 17, wherein: The instructions, when executed by the processor, further cause the event-driven module to determine a metric for the second file based on at least one of a namespace associated with the event or a file path associated with the event and an attribute of the file.

20. The system of claim 17, wherein: The attributes include file type attributes, file permission attributes, file name attributes, or file modification date attributes.

Images