Augmenting documentation with some notes about potential security risks

SECURITY.md

@@ -19,6 +19,10 @@ To report a potential security vulnerability in any NVIDIA product:
 
 While NVIDIA currently does not have a bug bounty program, we do offer acknowledgement when an externally reported security issue is addressed under our coordinated vulnerability disclosure policy. Please visit our [Product Security Incident Response Team (PSIRT)](https://www.nvidia.com/en-us/security/psirt-policies/) policies page for more information.
 
+## Scope Note: Model and Checkpoint Files
+
+TorchFort deserializes TorchScript models, TorchScript losses and checkpoints from paths supplied by the calling application. This includes all components of a checkpoint directory (optimizer, learning-rate scheduler, normalizer and replay/rollout buffer state), which are restored through the same LibTorch deserialization path as the model itself. These files are executable content and are treated as trusted input, on par with the application binary itself; the library performs no integrity or provenance verification on them. Establishing that trust is the responsibility of the calling application. See the "Model and Checkpoint File Trust" section of the Usage Guide for details.
+
 ## NVIDIA Product Security
 
 For all security-related concerns, please visit NVIDIA's Product Security portal at https://www.nvidia.com/en-us/security

docs/extras.rst

@@ -20,11 +20,17 @@ Set up Environment
 ------------------
 
 You need to specify your `wandb api token <https://docs.wandb.ai/guides/track/public-api-guide#authentication>`_ via the environment variable ``WANDB_API_KEY`` (see the `wandb documentation on available environment variables <https://docs.wandb.ai/guides/track/environment-variables#multiple-wandb-users-on-shared-machines>`_ for details).
-Furthermore, the daemon needs to know where the the wandb logging data from the TorchFort application will be stored. This can be done by defining the environment variable ``TORCHFORT_LOGDIR``. Lastly, a user0defined wandb logging directory ``WANDB_LOGGING_DIR`` can be created to gather all wandb information as well as the config file in a place specific to the run. 
+Furthermore, the daemon needs to know where the the wandb logging data from the TorchFort application will be stored. This can be done by defining the environment variable ``TORCHFORT_LOGDIR``. Lastly, a user-defined wandb logging directory ``WANDB_LOGGING_DIR`` can be created to gather all wandb information as well as the config file in a place specific to the run. 
 
 .. note::
     The logging directory ``TORCHFORT_LOGDIR`` needs to be specified before the daemon and TorchFort application are launched.
 
+.. note::
+    When ``enable_wandb_hook`` is set, TorchFort writes a copy of the run configuration and the metrics log file into ``TORCHFORT_LOGDIR``. The variable
+    is used as given, so it should point at a directory that is writeable by, and appropriate for, the user running the application. As with any
+    environment variable, it is part of the process launch environment and carries the privileges of the launching user; TorchFort does not run with
+    elevated privileges and does not attempt to restrict the location further.
+
 Start Background Watcher Process
 --------------------------------
 

docs/usage.rst

@@ -382,3 +382,27 @@ collected transitions (e.g. generated under the modified reward function) are no
 On-policy systems provide the equivalent function ``torchfort_rl_on_policy_load_model``, which restores only the actor-critic network weights and leaves the
 optimizer, learning-rate scheduler, rollout buffer, normalizer statistics and step counters in their freshly created state.
 
+.. _model_file_trust-ref:
+
+Model and Checkpoint File Trust
+===============================
+
+TorchFort loads TorchScript models, TorchScript losses and saved checkpoints through LibTorch's deserialization routines, either from the ``filename``
+parameter of a YAML configuration file or from a path passed directly to functions such as ``torchfort_load_model`` and ``torchfort_load_checkpoint``.
+A TorchScript archive is executable content, not plain data: it carries a serialized computation graph that may invoke any operator registered in the
+host process. Loading such a file is therefore equivalent to loading code into your program, and TorchFort applies no integrity or provenance checking
+beyond verifying that the file exists.
+
+The same consideration applies to every component of a checkpoint directory, not only to the network weights. Optimizer state, learning-rate scheduler
+state, model training state, running normalizer statistics and the replay and rollout buffers of the reinforcement learning systems are all restored
+through the same LibTorch deserialization path, since ``torch::load`` and ``torch::serialize::InputArchive`` are themselves implemented on top of the
+TorchScript module reader. A checkpoint directory should therefore be treated as a single trusted unit: it is not the case that only the model file is
+sensitive and the remaining tensor files are inert data.
+
+.. note::
+   Model files, loss files, checkpoints and the YAML configuration files that reference them must be treated as trusted input, at the same level of
+   trust as the simulation binary itself. Establishing that trust is the responsibility of the calling application and its deployment environment,
+   for example by restricting write access to model directories, transferring artifacts over authenticated channels, or verifying signatures or
+   checksums against a manifest before invoking TorchFort. Do not point TorchFort at model or checkpoint files obtained from untrusted or
+   unauthenticated sources.
+