zfs crypto discuss - Dec 2007 - [crypto-discuss] cryptoloop question

Mark Furner wrote:
>> lofiadm does not support twofish because the crypto framework
doesn''t
>> have a twofish provider 
> 
> I found a lofi-crypto-lofiadm.1m[1] manpage FWIW which has methods for 
> creating UFS and FAT file systems that could I guess apply to encrypted 
> loopback devices. 
Right but the filesystems are above lofi and know nothing about it, just 
like lofi knows nothing about the filesystem.   This is just like 
putting ufs or FAT ontop of a volume manager like SVM or VxVM.

Very much not like how ZFS works!
> So: ZFS file-system encryption is object-based.  A file system with
encryption
> enabled will NOT mount automatically (mount -a) at boot without the keys, 
> although the unencrypted metadata might support this,[2]  but... 
Correct.
> * Will ZFS-level file system and pool encryption then function like the 
> compression options: only on subsequently created data, but not 
> retrospectively? (Hmm interesting forensic implications for data
carving...)
No encryption is a create time only property it can not be set on an 
existing filesystem.
> * If one user has the "encryption" property delegated to them and
encrypts
> data, can other users without this delegation still mount it 
It depends on what the value of the keytype property is and if the other 
user has the mount delegation for that dataset.  Lets assume they do 
have the mount delegation, if they don''t it fails at that point.

If keytype is "pwrap" then it is a single per pool wrapping key, if 
someone has run ''zpool key -l <pool>'' and supplied the
correct pool key
then yes all encrypted datasets with keytype=pwrap will then mount.

If keytype is "dataset" then someone with the correct key needs to run
''zfs key -l <dataset>''.  I haven''t yet worked
out what the delegation
model for the key subcommand is, but I certainly want to have some 
interaction with delegation for it.

 >(ie. to access their own non-encrypted data on shared file systems?)

I assume you mean something like this:

[ Assuming that the default mount points are used ]

tank/home			encryption=off
tank/home/darrenm		encryption=on
tank/home/darrenm/shared	encryption=off

The dataset tank/home/darrenm won''t mount unless the key is present, 
that that means that tank/home/darrenm/shared won''t mount either.

What this means is that the key needs to be present to mount 
/tank/home/darrenm/shared even though it isn''t encrypted.

I don''t know how I can get around that since tank/home/darrenm needs to
be mounted before tank/home/darrenm/shared.
	
Now if tank/home/darrenm/shared actually has a mountpoint of /projects 
for example then it will mount even if tank/home/darrenm isn''t mounted.

 > How does the file
 > system handle simultaneous users in the same group where one has 
encrypted
 > data?

I don''t understand that question.  UNIX groups are irrelevant really, 
you need the key to get the dataset to mount after that the POSIX layer 
(ZPL) normal permissions, ACLs etc take over.

The encryption keys don''t change the permissions and ACL model at all, 
all they do is determine wither or not a filesystem can be mounted.


-- 
Darren J Moffat

> The encryption keys don''t change the permissions and ACL model at
all,
> all they do is determine wither or not a filesystem can be mounted.
Aren''t the encryption keys also used for real time (de)cryption
operations?
(Sorry if the question is plain stupid, I came late to the table.)

_________________________________________________________________
News, entertainment and everything you care about at Live.com. Get it now!
http://www.live.com/getstarted.aspx

Hi Darren

Thanks for the explanation (and patience). 

Regards

Mark.

On Wednesday 05 December 2007, Darren J Moffat (Darren J Moffat 
<darrenm at opensolaris.org>) may have written:
> Now if tank/home/darrenm/shared actually has a mountpoint of /projects
> for example then it will mount even if tank/home/darrenm isn''t
mounted.

a b wrote:
>> The encryption keys don''t change the permissions and ACL model
at all,
>> all they do is determine wither or not a filesystem can be mounted.
> 
> Aren''t the encryption keys also used for real time (de)cryption
operations?
The key that is loaded by ''zpool key -l'' or ''zfs key
-l'' is only used to
decrypt a key stored in the (hidden) dataset "wrappedkey" property,
that
unwrapping is done by the key loading operation (and that is all it 
does).  It is that unwrapped key that is used for the actual 
encryption/decryption of the stored data.   That is done "in real
time".
> (Sorry if the question is plain stupid, I came late to the table.)
The ACLs, owner etc, and file data are stored on disk encrypted with the 
"wrappedkey".

Hope I''m explaining it better now.

-- 
Darren J Moffat