US-20260127288-A1 - DYNAMIC KERNEL SECURITY MODULE WITH KERNEL-LEVEL SIGNED BINARY VALIDATION
Abstract
Disclosed embodiments relate to systems and methods for securing kernel-level system functions and validating kernel-level verification of signed binaries. Techniques include identifying, by a system patched by a kernel module, a file signed by a user; receiving, by the kernel module, a second key from the user; and validating the signature embedded in the file, by identifying the file; determining whether the signature is embedded in the file; and validating that the signature corresponds to the second key.
Inventors
- Dmitry Moskalchuk
- Ilya Abramovich
Assignees
- CYBERARK SOFTWARE LTD.
Dates
- Publication Date
- 20260507
- Application Date
- 20251229
Claims (20)
- 1 . A non-transitory computer readable medium including instructions that, when executed by at least one processor, cause the at least one processor to perform operations for dynamically validating kernel-level verification of signed binaries, the operations comprising: identifying, by a system patched by a kernel module, an executable file requested to be executed, wherein the executable file includes a cryptographic signature generated using a first key associated with a user, and wherein the cryptographic signature is embedded in the executable file; determining, by the kernel module, whether the executable file is signed based on at least one of file metadata, a file format structure, or a designated marker associated with the executable file; based on determining that the executable file is signed, identifying, by the kernel module, a second key associated with the user, wherein the second key is at least one of: stored in association with the kernel module or is provided to the kernel module by a user-space security agent; validating the cryptographic signature embedded in the executable file, the validating comprising: verifying the cryptographic signature using the second key; and based on a result of the verifying, allowing the request to be executed or denying the request to be executed.
- 2 . The non-transitory computer readable medium of claim 1 , wherein the first key and the second key are part of a public-private key pair.
- 3 . The non-transitory computer readable medium of claim 2 , wherein the first key is stored locally and does not leave a computing environment in which signing occurs.
- 4 . The non-transitory computer readable medium of claim 2 , wherein the second key is stored in association with the kernel module and is used for signature verification.
- 5 . The non-transitory computer readable medium of claim 1 , wherein the operations further comprise detecting tampering to the file, and wherein any modifications to the file invalidate the signature.
- 6 . The non-transitory computer readable medium of claim 1 , wherein the operations further comprise tracking the signature, wherein the executable file is signed multiple times by multiple users using multiple different keys, and tracking the signature comprises maintaining a log of all keys used to sign the executable file together with additional metrics comprising at least one of: a time stamp, an IP address, a network identity associated with the user, or the details of the organization.
- 7 . The non-transitory computer readable medium of claim 1 , wherein the operations are compatible with ELF files.
- 8 . The non-transitory computer readable medium of claim 1 , wherein the determining whether the signature has been embedded in the file further comprises determining whether the executable file is unsigned or signed based on an ELF header.
- 9 . The non-transitory computer readable medium of claim 8 , wherein when the file is determined to be unsigned, the checking whether the signature has been embedded in the file further comprises skipping subsequent steps to reduce computing overhead.
- 10 . The non-transitory computer readable medium of claim 8 , wherein when the executable file is determined to be signed, the checking whether the signature has been embedded in the executable file further comprises: enabling a kernel to read the entire file; and verifying the embedded signature.
- 11 . The non-transitory computer readable medium of claim 1 , wherein the system includes a user-selectable control configured to enable selective signing of critical files.
- 12 . A computer-implemented method for dynamically validating kernel-level verification of signed binaries, comprising: identifying, by a system patched by a kernel module, an executable file requested to be executed, wherein the executable file includes a cryptographic signature generated using a first key associated with a user, and wherein the cryptographic signature is embedded in the executable file; determining, by the kernel module, whether the executable file is signed based on at least one of file metadata, a file format structure, or a designated marker associated with the executable file; based on determining that the executable file is signed, identifying, by the kernel module, a second key associated with the user, wherein the second key is at least one of: stored in association with the kernel module or is provided to the kernel module by a user-space security agent; validating the cryptographic signature embedded in the executable file, the validating comprising: verifying the cryptographic signature using the second key; and based on a result of the verifying, allowing the request to be executed or denying the request to be executed.
- 13 . The computer-implemented method of claim 12 , wherein the first key and the second key are part of a public-private key pair.
- 14 . The computer-implemented method of claim 13 , wherein the first key is stored locally and does not leave a computing environment in which signing occurs.
- 15 . The computer-implemented method of claim 13 , wherein the second key is stored in association with the kernel module and is used for signature verification.
- 16 . The computer-implemented method of claim 12 , further comprising detecting tampering to the file, wherein any modifications to the executable file invalidate the signature.
- 17 . The computer-implemented method of claim 12 , further comprising tracking the signature, wherein the executable file is signed multiple times by multiple users using multiple different keys, and tracking the signature comprises maintaining a log of all keys used to sign the executable file together with additional metrics comprising at least one of: a time stamp, an IP address, a network identity associated with the user, or the details of the organization.
- 18 . The computer-implemented method of claim 12 , wherein the operations are compatible with ELF files.
- 19 . The computer-implemented method of claim 12 , wherein the determining whether the signature has been embedded in the executable file further comprises determining whether the file is unsigned or signed based on an ELF header.
- 20 . The computer-implemented method of claim 19 , wherein when the file is determined to be unsigned, the checking whether the signature has been embedded in the file further comprises skipping subsequent steps to reduce computing overhead.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS This application is a continuation-in-part of and claims the benefits of priority to U.S. application No. Ser. No. 19/354,412, filed Oct. 9, 2025, which is a continuation of U.S. application No. Ser. No. 18/883,251, filed on Sep. 12, 2024, each of which is incorporated by reference herein in its entirety. TECHNICAL FIELD The present disclosure relates generally to cybersecurity and, more specifically, to techniques for securing kernel-level system functions through hot patching a kernel, and validating kernel-level verification of signed binaries. BACKGROUND INFORMATION In modern network-based environments, it is increasingly important for organizations and individuals alike to securely control which users and processes are authorized to perform sensitive operations. Many computer systems enforce privileges to perform security-relevant functions through the use of one or more security policies. However, as various techniques are developed for enforcing these security policies, attackers continuously find ways to circumvent these measures. One solution to thwart would-be attackers is to implement security policies at the kernel level. For example, the Linux™ operating system supports the use of Linux Security Modules (LSM), which enable implementing a mandatory access control (MAC) module to protect such systems from attacks. These techniques allow individual applications to be isolated, which may limit access to attackers who have compromised part of a system. Example LSMs include AppArmor™ and SELinux™, which are included in many Linux™ kernel distributions. Despite the term “module,” however, these LSMs are a static part of the Linux™ kernel. These LSMs can be either enabled or disabled for a specific Linux kernel at build time and this choice cannot be changed thereafter. The LSMs become part of the module chain and are called by the LSM subsystem every time the security check is needed inside the Linux™ kernel. These techniques thus provide very minimal flexibility and cannot be altered in any way during runtime. Another example of security policies at the kernel level, whose implementation would allow for increased protection from would-be attackers, includes kernel-level verification of signed binaries. When executable files are introduced into a system or shared across systems, verifying their authenticity and integrity is important to ensure that executable code originates from a trusted source and has not been altered. Kernel-level validation based on signed binaries, for example using cryptographic signatures generated using a private key and verified using a corresponding public key, allows this verification to occur inside the Linux™ kernel prior to, or in connection with, execution of the executable file. Accordingly, in view of these and other deficiencies in existing techniques, technological solutions are needed for improving security at the kernel level while maintaining flexibility for users. In particular, solutions should advantageously provide the ability to enable or disable the security module at runtime, without requiring the kernel to be rebuilt, and to validate at the kernel level signed binaries to verify security or privacy of a file. SUMMARY The disclosed embodiments describe non-transitory computer readable media, systems, and methods for dynamically securing kernel-level system functions. For example, in an embodiment, a non-transitory computer readable medium may include instructions that, when executed by at least one processor, cause the at least one processor to perform operations for dynamically securing kernel-level system functions. The operations may comprise hot patching of a kernel by a kernel module loaded into the kernel; identifying a kernel function initiated by a system call associated with a user-level application; intercepting the kernel function by the kernel module; making available, to a security agent, an indication of at least one operation associated with the kernel function; receiving, from the security agent, a determination of whether the at least one operation associated with the kernel function violates at least one security policy; and based on the determination indicating the at least one operation does not violate the at least one security policy, allowing the system call to the kernel; or based on the determination indicating the at least one operation violates at least one security policy, performing at least one control action. According to a disclosed embodiment, prior to the hot patching, the kernel may be unaltered relative to a build time of the kernel. According to a disclosed embodiment, the kernel may be associated with a kernel distribution. According to a disclosed embodiment, the hot patching of the kernel may be performed based on a request from an additional application. According to a disclosed embodiment, the hot patching of the kernel may include replacing an instruction of a kernel functi