Nicolas Williams wrote: > On Tue, Jun 16, 2009 at 07:40:10AM -0700, Glenn Faden wrote: >> Darren J Moffat wrote: >>> Scratch that comment, on further thought (prompted by MarkS) I'm >>> actually not happy with using a dataset property for this. >>> >>> ZFS Crypto support doesn't encrypt the property names or values, this >>> means that the sensitivity labels will not be encrypted on disk. >>> That could be a serious issue for use cases that involve ZFS doing >>> encryption and having TX enabled. >>> >>> I think this case needs some discussion with the ZFS core team and the >>> ZFS crypto team before it can move forwards. >> You think the internal (hex) labels need to be encrypted? What is the >> alternative to using a system property? > > Well, they are static, no?
Static to a given site. The issue is that the labels themselves are classified information for some customers - usually only the compartment bits - and as such it would be better if we could encrypt them so that the handling of disks that contain labels could be reduced. > Therefore at the very least there's a traffic analysis issue. > But given that we don't encrypt anything in ZFS > now I would think it'd be fine for the ZFS crypto project to leave > dataset properties unencrypted and _later_ come back and address that > problem, leaving this case and ZFS crypto orthogonal to each other. Given that ZFS crypto explicitly has all properties (including user properties) in the clear I was trying to ensure that this case didn't build an architecture that mean't it wasn't possible to have the TX label encrypted. If a dnode system attribute rather than a dataset property was used then it would automatically be encrypted by ZFS crypto. However it seems that the desire is to know the label before not after mounting so a property needs to be used. -- Darren J Moffat
