The Validated Execution project is investigating how to utilize ZFS
snapshots as the basis of a "validated" filesystem. Given that the
blocks of the dataset form a Merkel tree of hashes, it seemed
straightforward to validate the individual objects in the snapshot and
then sign the hash of the root as a means of indicating that the
contents of the dataset were validated.
Unfortunately, the block hashes are used to assure the integrity of the
physical representation of the dataset. Those hash values can be
updated during scrub operations, or even during data error recovery,
while the logical content of the dataset remains intact. This would
invalidate the signature mechanism proposed above, even though the
logical content remains undisturbed.
We want to build on the data integrity given us by ZFS. However, we
need some means of knowing that the dataset we are currently using is
in fact the same snapshot that was validated earlier. We can't use the
name, since cloning, promotion, and renaming can lead to a different
snapshot having the name under which the prior snapshot was validated.
My attempt to forge a replacement snapshot stumbled over the creation
time property, but that seems capable of duplication with minimal
effort.
Does the snapshot dataset include identity information? While a dataset
index would be a help, is there perhaps a UUID generated when the
snapshot is taken?
With regard to the signing mechanism, it might be useful to be able to
set properties on a snapshot. Since ZFS expressly prohibits this, how
feasible would it be to provide for creation of a snapshot from a
snapshot while setting a specific property on the child snapshot, thus
avoiding the exposure to modification of the filesystem objects that
cloning and snapshotting would entail?
Thanks -JZ
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
