Trusting files loaded after start of enclave
As mentioned previously, the enclave software measurement is a computation of the enclave memory before it starts running. Yet there are situations where the measurement does not include all of the files used during runtime. This is because some languages load some of the code during execution time, and not ahead of time.
One example is a dynamically loaded library. These libraries are not a part of the executable when it starts. Another example is a Python dependency - when running a Python script, it will start loading libraries dynamically, after the Python program has started.
This means that code that will run eventually in the enclave is not part of the code that is measured before the enclave starts to run. As a result, the enclave software measurement does not contain this dynamically loaded code. This in turn can introduce a risk, as a malicious user can alter the application’s behavior by changing its dynamically loaded dependencies on the production server.
To mitigate this type of security risk, the Anjuna Runtime provides a mechanism to define code that will get loaded into the enclave after it is started, and this code’s measurement will be included as part of the manifest file of the enclave. The definition of these dependencies includes the path of the file to be loaded as well as the measurement (hash value) of each file.
It is important to note that the manifest file is a part of the enclave’s initial memory, so the manifest is included in the enclave software measurement. Therefore, the same application with two different manifests will create two different software measurements. This prevents a malicious user from changing the manifest for an enclave so that the software running in the enclave can still be trusted.
Running an enclave in non-strict or strict mode
You can run the enclave with the Anjuna Runtime in one of two modes; in a non-strict mode, or in a strict mode.
The non-strict mode
In this mode,
if the file to be loaded is not a part of the manifest or if the file has a different measurement
from the one in the manifest, a warning will be printed to stderr,
but the software will still be able to load the file.
The non-strict mode is available only in the case where the enclave is not running in production
mode.
anjuna-runtime will run in a non-strict mode when run with
the --dev parameter.
anjuna-sgxrun is a script that runs anjuna-runtime
with the --dev parameter.
The strict mode
In this mode,
if the file to be loaded is not a part of the manifest or if the file has a different measurement
from the one in the manifest,
the application will get a permission denied response when trying to load this file,
and the Anjuna Runtime prints a warning to stderr.
The result is dependent on the application - in some cases the application will decide to stop,
and in other cases the application may continue and try to overcome this problem.
For example - in the case of a dynamically loaded dependency, the application may continue to look
for the dependency in another location.
Recommended development flow
The following flow is recommended for any type of dynamic dependency:
-
During development, it is recommended to run the enclave in the non-strict mode, identify the dynamic dependencies, and add them to the manifest template (as explained below).
-
During testing, it is recommended to run in both non-strict mode and then in the strict mode.
-
The first phase is to identify the missing dependencies, without failing the test on each missing dependency.
-
The second phase is to make sure that no dynamic dependencies were missed by mistake.
-
-
And of course in production, the enclave should run in the strict mode (by setting the
is_productionflag to “true”).