Impact
in-toto verifies the integrity of all files by using cryptographically secure hashes, but the integrity of file metadata is not verified and therefore not ensured by the process. This includes file permissions, timestamps and additional associated data such as NTFS alternate data streams.
The impact of this depends on the individual project and files associated. File permissions might be changed to very permissive, which allows local privilege escalations after installing the final product. Additionally, removing the executable permission from a file might cause the software to behave in insecure ways (one might imagine a SecurityHelper.exe could be prevented from running).
Workarounds
X41 recommends to verify file metadata as well or at least provide tools to do so. If this is not possible, it should be advised to always place the files in a container format that specifies permissions.
The in-toto specification focuses on bit-for-bit equivalence of the content of artifacts and does not consider accompanying artifact metadata. This enables in-toto to be agnostic of specific operating systems and filesystems. File metadata tends to be brittle (when it's possible to capture them) and it is tricky to translate attribute values between different underlying filesystems. Other systems such as Git have encountered bugs in the past due to such issues and have also settled for not recording all file metadata.
in-toto adopters have several options to validate file attributes. Supply chain owners can leverage ITE-4 semantics to wrap files in a format that includes attributes that need to be verified. Alternative, in-toto layouts may include inspections that validate specific attributes such as permissions of an artifact separately.
References
Impact
in-toto verifies the integrity of all files by using cryptographically secure hashes, but the integrity of file metadata is not verified and therefore not ensured by the process. This includes file permissions, timestamps and additional associated data such as NTFS alternate data streams.
The impact of this depends on the individual project and files associated. File permissions might be changed to very permissive, which allows local privilege escalations after installing the final product. Additionally, removing the executable permission from a file might cause the software to behave in insecure ways (one might imagine a
SecurityHelper.execould be prevented from running).Workarounds
X41 recommends to verify file metadata as well or at least provide tools to do so. If this is not possible, it should be advised to always place the files in a container format that specifies permissions.
The in-toto specification focuses on bit-for-bit equivalence of the content of artifacts and does not consider accompanying artifact metadata. This enables in-toto to be agnostic of specific operating systems and filesystems. File metadata tends to be brittle (when it's possible to capture them) and it is tricky to translate attribute values between different underlying filesystems. Other systems such as Git have encountered bugs in the past due to such issues and have also settled for not recording all file metadata.
in-toto adopters have several options to validate file attributes. Supply chain owners can leverage ITE-4 semantics to wrap files in a format that includes attributes that need to be verified. Alternative, in-toto layouts may include inspections that validate specific attributes such as permissions of an artifact separately.
References