Abstract: Techniques allow runtime extensions to a whitelist that locks down a computational system. For example, executable code is not only subject to whitelist checks that allow (or deny) its execution, but is also subject to checks that determine whether a whitelisted executable is itself trusted to introduce further executable code into the computational system in which it is allowed to run. In general, deletion and/or modification of instances of code that are already covered by the whitelist are also disallowed in accordance with a security policy. Accordingly, an executable that is trusted may be allowed to delete and/or modify code instances covered by the whitelist. In general, trust may be coded for a given code instance that seeks to introduce, remove or modify code.

Abstract: Techniques have been developed to allow runtime extensions to a whitelist that locks down a computational system. For example, executable code (including e.g., objects such as a script or active content that may be treated as an executable) is not only subject to whitelist checks that allow (or deny) its execution, but is also subject to checks that determine whether a whitelisted executable is itself trusted to introduce further executable code into the computational system in which it is allowed to run. In general, deletion and/or modification of instances of code that are already covered by the whitelist are also disallowed in accordance with a security policy. Accordingly, an executable that is trusted may be allowed to delete and/or modify code instances covered by the whitelist. In general, trust may be coded for a given code instance that seeks to introduce, remove or modify code (e.g., in the whitelist itself).