DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . In communications filed on 02/17/2026. Claims 1, 10-11 are amended. Claim 13 is cancelled. Claims 1-12 are pending in this examination.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. This examination is in response to US Patent Application No. 18/841,958.
Response to Arguments
.
Applicant’s argument on page 6 of remarks filed on 02/ 17/ 2026 obviates previously raised claims 1-13 claims objection.
Applicant’s amendment to claims 1, and 10-11 obviates previously raised claims 1, 10-11 112(b), second paragraph rejection regarding the wording “being” in the claims.
Applicant's arguments filed 02/17/2026 have been fully considered but they are not persuasive:
Applicant submits on pages 7-12 of remarks filed on 02/17/2026 regarding claim 1 that the recited features of an attack vector specifically targeting a function to be protected, the reception of a mitigation policy identifier from a security management server, and the sending of a message to such a server including data representative of the attacked process, are not disclosed by the cited combination.
Examiner respectfully disagrees with applicant argument for claim 1 filed on 02/17/2026 on pages 7-12 of remarks. Examiner maintain the rejection.
Belair discloses:
an attack vector specifically targeting a function to be protected
[0009] More specifically, and according to a first aspect, the invention relates to a method of securing at least one system call triggered by a current process of a user space of a software system. This process is implemented by a kernel of the software system before executing at least one operation triggered by said at least one system call and includes: - a step of obtaining at least one kernel namespace dedicated to security management associated with the current process; - a step to determine if said at least one namespace contains a security policy associated with said operation and recorded in a kernel area; - a step of executing the security policy; and - a step of processing the system call according to a result of this execution.], and [0010] Thus, and in general, the invention proposes a mechanism allowing a process or set of processes in user space to define its own security policies to be implemented by the kernel. , and [0015] The invention also relates to a device comprising a user space and a kernel, the user space comprising at least one process capable of triggering at least one system call from the kernel. This device is characterized in that: - the kernel includes a security control infrastructure and a security module, this infrastructure being configured to execute the security module before executing at least one operation triggered by the system call; - said security module being configured to: - obtain at least one kernel namespace dedicated to security management associated with the process; - determine if said at least one namespace contains a security policy associated with the operation and registered in an area of said kernel; and - execute said at least one security policy], and [0023, In one particular embodiment, the software stack or user space container builds executable code that contains its own security policies applicable to particular operations (opening a file, receiving a network packet, ...).This code can be loaded at runtime (i.e., dynamically) through a system interface to the kernel. It is then executed by the kernel when these operations (or events) occur for a process belonging to that container. Since this code is not necessarily executed by a trusted (potentially malicious) process, it must not be able to interfere with the rest of the system or the kernel. Thus, security policies are only applied if they correctly refer to the container that originated the policy applicable to the event], and, [0098] In the embodiment described here, a security policy, and in particular the PSOFC1 security policy, returns a negative RET result if it detects a security problem (for example, reflecting malicious or abnormal behavior) and a positive result if it does not detect any security problem].
the reception of a mitigation policy identifier from a security management server
[0009] More specifically, and according to a first aspect, the invention relates to a method of securing at least one system call triggered by a current process of a user space of a software system. This process is implemented by a kernel of the software system before executing at least one operation triggered by said at least one system call and includes: - a step of obtaining at least one kernel namespace dedicated to security management associated with the current process; - a step to determine if said at least one namespace contains a security policy associated with said operation and recorded in a kernel area; - a step of executing the security policy; and - a step of processing the system call according to a result of this execution.[0013] According to a second aspect, the invention relates to a method of implementing a security policy, this method being implemented by a software stack of a user space of a software system to secure at least one system call likely to be triggered by a process of the software stack. This process includes a step of loading the security policy into an area of the kernel of said system, said security policy being associated with a namespace dedicated to security management associated with an operation likely to be triggered by said at least one system call of this process], and [0060] The invention proposes a security management mechanism to secure system calls triggering operations sensitive in the sense of Linux Security Modules (LSM)], and [0086, In the embodiment described here, the KER kernel includes a Linux Security Modules management security control infrastructure (ICS), a Linux security module LSM1 conforming to the invention and optionally at least one other security module LSM2, for example, a SELinux module or an AppAmor module].
Furthermore, Ismael discloses the limitation as: [¶92, In an embodiment, upon the start of the policy manager 122 or after the policy configuration is received by the policy manager 122, the policy manager 122 pushes a policy to a particular one of the active security policy enforcers 117A-117N for which the process allow list is to apply. The decision on what guest operating system or application for which the policy is to apply may depend on the configuration of the computing device 100. For the purposes of this example, the policy manager 122 pushes a process allow list policy to the active security policy enforcer 117A. The policy manager 122 may also push the profile of the target system to the active security policy enforcer 117A, which defines information such as the location
the sending of a message to such a server including data representative of the attacked process
[0098] In the embodiment described here, a security policy, and in particular the PSOFC1 security policy, returns a negative RET result if it detects a security problem (for example, reflecting malicious or abnormal behavior) and a positive result if it does not detect any security problem.[0099] If this RET value is positive, the security module determines, if it exists, the parent namespace of the current process namespace (step E60) and the loop repeats. [0100] In this case, during the second iteration, the PSOFp0 security policy of the ENSECURE0 namespace of process p0 is executed. [0101] If a security policy returns a negative RET result, the security module records this result in a kernel KER FLOG file during step E70 and sends this negative RET result to the ICS security infrastructure. This FLOG file can be analyzed (step F30) by the administrator using the ADM administration tool. [0102] When all security policies across the entire namespace tree have been executed with a positive RET result, the LSM1 security module sends a positive RET result to the ICS security infrastructure (test E90)].
CLAIM INTERPRETATION
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “computer configured to…” in claim 10, and “a submodule for receiving…”, and “a submodule for installing…” , and “an execution submodule configured to…”, and “a sending submodule configured to…” in claim 10, and “security management server configured to…” in claim 11.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION. —The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 10 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) are: “a submodule for receiving…”, and “a submodule for installing…” , and “an execution submodule configured to…”, and “a sending submodule configured to…” in claim 10.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claims limitation “a submodule for receiving…”, and “a submodule for installing…” , and “an execution submodule configured to…”, and “a sending submodule configured to…” in claim 10 invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-12 are rejected under 35 U.S.C. 103 as being unpatentable over FR3110726A1 issued to MAXIME BELAIR, hereinafter, “Belair” filed in IDS 08/27/2024, and in view of US Patent No. (US2022/0114009) issued to Ismael.
Regarding claim 1, Belair discloses a method for detecting an attempted computer attack implemented by a computer of a fleet of computers, said attack exploiting a vulnerability of a function to be protected executing in a process of a user space of said computer, a launching of the execution of said function to be protected resulting in the execution, before said attack, of a function of a kernel [0009] More specifically, and according to a first aspect, the invention relates to a method of securing at least one system call triggered by a current process of a user space of a software system. This process is implemented by a kernel of the software system before executing at least one operation triggered by said at least one system call and includes: - a step of obtaining at least one kernel namespace dedicated to security management associated with the current process; - a step to determine if said at least one namespace contains a security policy associated with said operation and recorded in a kernel area; - a step of executing the security policy; and - a step of processing the system call according to a result of this execution.], and [0010] Thus, and in general, the invention proposes a mechanism allowing a process or set of processes in user space to define its own security policies to be implemented by the kernel. , and [0015] The invention also relates to a device comprising a user space and a kernel, the user space comprising at least one process capable of triggering at least one system call from the kernel. This device is characterized in that: - the kernel includes a security control infrastructure and a security module, this infrastructure being configured to execute the security module before executing at least one operation triggered by the system call; - said security module being configured to: - obtain at least one kernel namespace dedicated to security management associated with the process; - determine if said at least one namespace contains a security policy associated with the operation and registered in an area of said kernel; and - execute said at least one security policy], and [0023, In one particular embodiment, the software stack or user space container builds executable code that contains its own security policies applicable to particular operations (opening a file, receiving a network packet, ...).This code can be loaded at runtime (i.e., dynamically) through a system interface to the kernel. It is then executed by the kernel when these operations (or events) occur for a process belonging to that container. Since this code is not necessarily executed by a trusted (potentially malicious) process, it must not be able to interfere with the rest of the system or the kernel. Thus, security policies are only applied if they correctly refer to the container that originated the policy applicable to the event], and, [0098] In the embodiment described here, a security policy, and in particular the PSOFC1 security policy, returns a negative RET result if it detects a security problem (for example, reflecting malicious or abnormal behavior) and a positive result if it does not detect any security problem].; and
executing said mitigation policy in said kernel, said mitigation policy being associated with said kernel function of said kernel and being loaded into a kernel namespace associated with said process and dedicated to security [0009] the invention relates to a method of securing at least one system call triggered by a current process of a user space of a software system. This process is implemented by a kernel of the software system before executing at least one operation triggered by said at least one system call and includes: - a step of obtaining at least one kernel namespace dedicated to security management associated with the current process; - a step to determine if said at least one namespace contains a security policy associated with said operation and recorded in a kernel area; - a step of executing the security policy; and - a step of processing the system call according to a result of this execution], and [0011]The invention finds a privileged application in the Linux environment but can be applied to any operating system offering a mechanism for isolating resources by namespace. Indeed, the invention proposes to define a new namespace dedicated to security management and to define security policies in these namespaces]; and
and, in response to detection by said mitigation policy during its execution of an attack vector supported by said policy and targeting said function to be protected, sending to said security management server a message including a data representative of said process [0098] In the embodiment described here, a security policy, and in particular the PSOFC1 security policy, returns a negative RET result if it detects a security problem (for example, reflecting malicious or abnormal behavior) and a positive result if it does not detect any security problem.[0099] If this RET value is positive, the security module determines, if it exists, the parent namespace of the current process namespace (step E60) and the loop repeats. [0100] In this case, during the second iteration, the PSOFp0 security policy of the ENSECURE0 namespace of process p0 is executed. [0101] If a security policy returns a negative RET result, the security module records this result in a kernel KER FLOG file during step E70 and sends this negative RET result to the ICS security infrastructure. This FLOG file can be analyzed (step F30) by the administrator using the ADM administration tool. [0102] When all security policies across the entire namespace tree have been executed with a positive RET result, the LSM1 security module sends a positive RET result to the ICS security infrastructure (test E90)]; and
said method including steps of receiving, from a security management server, a mitigation policy identifier, installing, in said kernel, a mitigation policy corresponding to said mitigation policy identifier [0009] More specifically, and according to a first aspect, the invention relates to a method of securing at least one system call triggered by a current process of a user space of a software system. This process is implemented by a kernel of the software system before executing at least one operation triggered by said at least one system call and includes: - a step of obtaining at least one kernel namespace dedicated to security management associated with the current process; - a step to determine if said at least one namespace contains a security policy associated with said operation and recorded in a kernel area; - a step of executing the security policy; and - a step of processing the system call according to a result of this execution.[0013] According to a second aspect, the invention relates to a method of implementing a security policy, this method being implemented by a software stack of a user space of a software system to secure at least one system call likely to be triggered by a process of the software stack. This process includes a step of loading the security policy into an area of the kernel of said system, said security policy being associated with a namespace dedicated to security management associated with an operation likely to be triggered by said at least one system call of this process], and [0060] The invention proposes a security management mechanism to secure system calls triggering operations sensitive in the sense of Linux Security Modules (LSM)], and [0086, In the embodiment described here, the KER kernel includes a Linux Security Modules management security control infrastructure (ICS), a Linux security module LSM1 conforming to the invention and optionally at least one other security module LSM2, for example, a SELinux module or an AppAmor module].
Belair does not explicitly disclose; however, Ismael discloses [¶92, In an embodiment, upon the start of the policy manager 122 or after the policy configuration is received by the policy manager 122, the policy manager 122 pushes a policy to a particular one of the active security policy enforcers 117A-117N for which the process allow list is to apply. The decision on what guest operating system or application for which the policy is to apply may depend on the configuration of the computing device 100. For the purposes of this example, the policy manager 122 pushes a process allow list policy to the active security policy enforcer 117A. The policy manager 122 may also push the profile of the target system to the active security policy enforcer 117A, which defines information such as the location of functions within the target kernel], and [ see FIG.1 and corresponding text for more details].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Belair by incorporating “policy manager and active security policy enforcer”, as taught by Ismael. One could have been motivated to do so in order for the active security and policy enforcement continuously monitors for semantic behavior detection or policy violations and enforces the policies at the virtualization layer, the policy manager 122 push the profile of the target system to the active security policy enforcer 117A, which defines information such as the location of functions within the target kernel [ Ismael, ¶¶6, 92, FIG.1].
Regarding claim 2, Belair discloses wherein the execution of said function to be protected leads to the execution of another function of said user space which leads to the execution of said function of the kernel 0006] As is known to those skilled in the art, these policies are applied at the kernel level in "hooks" (primitives allowing LSM modules to execute arbitrary "pieces of code" during sensitive operations (opening a file, receiving a network packet, ...)).[0009] More specifically, and according to a first aspect, the invention relates to a method of securing at least one system call triggered by a current process of a user space of a software system. This process is implemented by a kernel of the software system before executing at least one operation triggered by said at least one system call and includes: - a step of obtaining at least one kernel namespace dedicated to security management associated with the current process; - a step to determine if said at least one namespace contains a security policy associated with said operation and recorded in a kernel area; - a step of executing the security policy; and - a step of processing the system call according to a result of this execution.[0015]The invention also relates to a device comprising a user space and a kernel, the user space comprising at least one process capable of triggering at least one system call from the kernel. This device is characterized in that: - the kernel includes a security control infrastructure and a security module, this infrastructure being configured to execute the security module before executing at least one operation triggered by the system call; - said security module being configured to: - obtain at least one kernel namespace dedicated to security management associated with the process; - determine if said at least one namespace contains a security policy associated with the operation and registered in an area of said kernel; and - execute said at least one security policy. [0017] More specifically, in this embodiment, the process includes: - a step to obtain the namespace(s) dedicated to security management and ancestor(s) of the current process namespace; - a step to determine if this or these namespace(s) include a security policy associated with the operation and recorded in a kernel area; - a step to execute this security policy; and - a step to process the system call based on a result of this execution.
Regarding claim 3, Belair discloses wherein said mitigation policy is loaded into a namespace dedicated to security and associated with a root process of said computer [0015]
The invention also relates to a device comprising a user space and a kernel, the user space comprising at least one process capable of triggering at least one system calls from the kernel. This device is characterized in that: - the kernel includes a security control infrastructure and a security module, this infrastructure being configured to execute the security module before executing at least one operation triggered by the system call; - said security module being configured to: - obtain at least one kernel namespace dedicated to security management associated with the process; - determine if said at least one namespace contains a security policy associated with the operation and registered in an area of said kernel; and - execute said at least one security policy. 0017] More specifically, in this embodiment, the process includes: - a step to obtain the namespace(s) dedicated to security management and ancestor(s) of the current process namespace; - a step to determine if this or these namespace(s) include a security policy associated with the operation and recorded in a kernel area; - a step to execute this security policy; and - a step to process the system call based on a result of this execution.[0023] In one particular embodiment, the software stack or user space container builds executable code that contains its own security policies applicable to particular operations (opening a file, receiving a network packet, ...).This code can be loaded at runtime (i.e., dynamically) through a system interface to the kernel. It is then executed by the kernel when these operations (or events) occur for a process belonging to that container. Since this code is not necessarily executed by a trusted (potentially malicious) process, it must not be able to interfere with the rest of the system or the kernel. Thus, security policies are only applied if they correctly refer to the container that originated the policy applicable to the event.
Regarding claim 4, wherein said security server is configured to send the mitigation policy identifier to a plurality of computers of said fleet of computers.
While Belair discloses: [0014] Thus, and very advantageously, the security policy can be loaded by the software stack into the kernel, even when the latter does not have privileged administrative rights. This feature is particularly advantageous because state-of-the-art LSM modules require that policies be implemented by a user space entity with administrative rights. [0019] Particularly advantageously, security policies can be loaded by the software stack or by the container "on the fly," that is, while the container is running. [0023] In one particular embodiment, the software stack or user space container builds executable code that contains its own security policies applicable to particular operations (opening a file, receiving a network packet, ...). This code can be loaded at runtime (i.e., dynamically) through a system interface to the kernel. [0083] When a container is created, for example C1, the PSOFC1 and PCTPC1 security policies of container C1 are copied from ROM 12 into a memory M1 of container C1. Once the C1 container is built, it is executed and at runtime, the security policies are transferred from memory M1, into the ZPS area of the kernel.
Furthermore, Ismael discloses [¶92, In an embodiment, upon the start of the policy manager 122 or after the policy configuration is received by the policy manager 122, the policy manager 122 pushes a policy to a particular one of the active security policy enforcers 117A-117N for which the process allow list is to apply. The decision on what guest operating system or application for which the policy is to apply may depend on the configuration of the computing device 100. For the purposes of this example, the policy manager 122 pushes a process allow list policy to the active security bpfsystem to the active security policy enforcer 117A, which defines information such as the location of functions within the target kernel], and [ see FIG.1 and corresponding text for more details].
Regarding claim 5, wherein said installation step includes sub-steps of: sending a request including said mitigation policy identifier to a security server; obtaining, in response to the request, a file describing said mitigation policy; obtaining an object code of the mitigation policy identified in said description file; generating an executable code of said mitigation policy from said object code; and installing the executable code in said kernel.
While Belair discloses: [0034] These support functions (in English "helpers") can be loaded "hot", that is, during the execution of the kernel. They can be called by an eBPF security policy to perform critical operations such as accessing kernel structures for eBPF code. These support functions can only be written by an entity with administrative rights and are not subject to the limitations of the eBPF verifier. [0078] In the embodiment described here, each of the security policies PSOFp0, PSOFC1, PSTPC1 is defined by a software function in eBPF language compiled into binary. These security policies are stored in read-only memory 12 of device 100 and are intended to be loaded into the ZPS security policy area of the KER kernel. [0082] In the embodiment described here, the OCI configuration file of a container contains instructions for the container to load its security policies into the KER kernel security policy ZPS zone. [0085] Furthermore, loading a container-specific security policy into kernel memory can be done at any time during the container's lifecycle, not just at its initialization. In the embodiment described here, the C1 container code also includes load_ps() instructions to load a security policy as a binary-compiled eBPF file into the KER kernel's security policy ZPS. This particular embodiment allows, in particular, the loading of a new security policy that will be applied after the C1 container starts. This load_ps() function consists of opening the eBPF file contained in read-only memory 12 and copying it to an interface with the KER kernel, and [0017].
Furthermore, Ismael discloses [¶92, In an embodiment, upon the start of the policy manager 122 or after the policy configuration is received by the policy manager 122, the policy manager 122 pushes a policy to a particular one of the active security policy enforcers 117A-117N for which the process allow list is to apply. The decision on what guest operating system or application for which the policy is to apply may depend on the configuration of the computing device 100. For the purposes of this example, the policy manager 122 pushes a process allow list policy to the active security policy enforcer 117A. The policy manager 122 may also push the profile of the target system to the active security policy enforcer 117A, which defines information such as the location of functions within the target kernel], and [ see FIG.1 and corresponding text for more details].
Regarding claim 6, Belair discloses wherein said step of sending said at least one message to the security management server is implemented from said user space in response to said kernel sending a signal to said user space in order to notify said detection of said attack vector [0104] In the embodiment described here, if the RET security infrastructure receives a negative RET result, the ICS control infrastructure triggers an AS security action during an E80 step. This action may involve destroying the process that initiated the call and raising an alert in the FLOG log file. [0101] If a security policy returns a negative RET result, the security module records this result in a kernel KER FLOG file during step E70 and sends this negative RET result to the ICS security infrastructure. This FLOG file can be analyzed (step F30) by the administrator using the ADM administration tool.
Regarding claim 7, Belair discloses wherein said at least one message includes at least one piece of information among: an identifier of said computer; a data representative of said namespace associated with said process and dedicated to security; an identifier of said vulnerability; a time at which the execution of the mitigation policy has been triggered
[0002] In this document, the protection of a system call consists more specifically of protecting access (read/create/modify/delete...) to sensitive kernel resources (inodes, files, etc.) that may be triggered in the system call code from user space, for example, to manage sensitive operations such as opening a file, sending a packet, creating an "inode", etc.[0009] More specifically, and according to a first aspect, the invention relates to a method of securing at least one system call triggered by a current process of a user space of a software system. This process is implemented by a kernel of the software system before executing at least one operation triggered by said at least one system call and includes: - a step of obtaining at least one kernel namespace dedicated to security management associated with the current process; - a step to determine if said at least one namespace contains a security policy associated with said operation and recorded in a kernel area; - a step of executing the security policy; and - a step of processing the system call according to a result of this execution.[0015] The invention also relates to a device comprising a user space and a kernel, the user space comprising at least one process capable of triggering at least one system call from the kernel. This device is characterized in that: - the kernel includes a security control infrastructure and a security module, this infrastructure being configured to execute the security module before executing at least one operation triggered by the system call; - said security module being configured to: - obtain at least one kernel namespace dedicated to security management associated with the process; - determine if said at least one namespace contains a security policy associated with the operation and registered in an area of said kernel; and - execute said at least one security policy.[0083] When a container is created, for example C1, the PSOFC1 and PCTPC1 security policies of container C1 are copied from ROM 12 into a memory M1 of container C1. Once the C1 container is built, it is executed and at runtime, the security policies are transferred from memory M1, into the ZPS area of the kernel. [0085] Furthermore, loading a container-specific security policy into kernel memory can be done at any time during the container's lifecycle, not just at its initialization. In the embodiment described here, the C1 container code also includes load_ps() instructions to load a security policy as a binary-compiled eBPF file into the KER kernel's security policy ZPS. This particular embodiment allows, in particular, the loading of a new security policy that will be applied after the C1 container starts. This load_ps() function consists of opening the eBPF file contained in read-only memory 12 and copying it to an interface with the KER kernel.
Regarding claims 8, and 10-12, these claims are interpreted and rejected for the same rational set forth in claim 1.
Regarding claim 9, Belair does not explicitly disclose, however, Ismael discloses a step of sending, to a plurality of computers in the fleet of computers, said identifier of the mitigation policy [ see FIG.1, ¶28, The virtualized system includes one or more guest operating systems 110A-N and guest applications 111A-N respectively running on top of one or more virtual machines 108A-N respectively. The guest OS and applications may be unmodified. In an embodiment, each virtual machine has a separate virtual machine monitor (VMM) with virtual machine introspection (VMI) and separate active security policies, which ensures maximum process and memory segregation. Thus, the VMM 115A, VMI 116A, and the active security policy enforcer 117A are dedicated for the guest operating system 110A and guest applications 111A running on the virtual machine 108A; and the VMM 115N, VMI 116N, and the active security policy enforcer 117N are dedicated for the guest OS 110N and guest applications 111N running on the virtual machine 108N], and [¶92, In an embodiment, upon the start of the policy manager 122 or after the policy configuration is received by the policy manager 122, the policy manager 122 pushes a policy to a particular one of the active security policy enforcers 117A-117N for which the process allow list is to apply. The decision on what guest operating system or application for which the policy is to apply may depend on the configuration of the computing device 100. For the purposes of this example, the policy manager 122 pushes a process allow list policy to the active security policy enforcer 117A. The policy manager 122 may also push the profile of the target system to the active security policy enforcer 117A, which defines information such as the location of functions within the target kernel].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Belair by incorporating “policy manager and active security policy enforcer”, as taught by Ismael. One could have been motivated to do so in order for the active security and policy enforcement continuously monitors for semantic behavior detection or policy violations and enforces the policies at the virtualization layer, the policy manager 122 push the profile of the target system to the active security policy enforcer 117A, which defines information such as the location of functions within the target kernel [ Ismael, ¶¶6, 92, FIG.1].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's
disclosure.
See submitted 892 for more relevant references.
Doukhvalov ( US20170005983) [0070] The transmission of the message is monitored as follows: [0071] entity B 202 requests transmission of the message to entity C 203 by calling up a function of the operating system's kernel; [0072] the microkernel compares entity's C 203 gateway C 213 with the entity; [0073] gateway C 213 reflects the request onto the security policies; [0074] gateway C 213 calls the security server 210, transmitting references to policies, the SIDs of the security contexts of entity B 202 and of entity C 203, and the selected parameters of the message (which the policies may need) for the computation of a security verdict; [0075] the security server 210 computes the verdict; [0076] if the verdict is positive, the transmission of the message is permitted; [0077] in the opposite case, the transmission of the message is forbidden, and an error message is returned.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHAHRIAR ZARRINEH whose telephone number is (571)272-1207. The examiner can normally be reached Monday-Friday, 8:30am-5:30pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jorge Ortiz-Criado can be reached at 571-272-7624. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SHAHRIAR ZARRINEH/Primary Examiner, Art Unit 2496
Prosecution Insights