On Tue, Jun 16, 2009 at 07:59:06PM +0100, Darren J Moffat wrote: > >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.
The internal encoding is supposed to make the label useless to a human. In practice, unless there are many ways to encode a single label, then traffic analysis is possible: > > 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. Sure, you could use an extended attribute of the dataset's root dnode, which would work fine for filesystem type datasets and their snapshots, but sadly not for zvols. > However it seems that the desire is to know the label before > not after mounting so a property needs to be used. Why can't the system go through the motions all the way up to decrypting the relevant items, then evaluate labeled security policy and only then (assuming the MAC allows it) complete the mount? It seems to me that whether the slabel property is a dataset property or an attribute of the root dnode is an implementation detail from that p.o.v. Nico --
