zfs crypto discuss - Oct 2007 - ZFS Crypto Alpha Release

I''m pleased to announce that the ZFS Crypto project now has Alpha 
release binaries that you can download and try.   Currently we only have 
x86/x64 binaries available, SPARC will be available shortly.

Information on the Alpha release of ZFS Crypto and links for downloading 
the binaries is here:

http://opensolaris.org/os/project/zfs-crypto/phase1/alpha/

Please pay particular note to the important information at the top of 
the above page.

One of the main purposes of this Alpha release is to get feedback so 
that we can complete the design and schedule our second design review 
and our PSARC commitment review.

Note the the feature set is NOT committed at this time, neither is the 
user interface.

-- 
Darren J Moffat

Author: Darren Moffat <darrenm at opensolaris.org>
Repository: /hg/zfs-crypto/zfs-crypto-gate
Latest revision: 1699184b44572313f742d3515ebabbca3959136a
Total changesets: 1
Log message:
ZFS Crypto Alpha Release

Files:
	update: .hgtags

Looks great.. Any (long-term distant-future) plans of integrating this with the
Trusted Extensions for a real quick setup?  With a check to make sure the
key''s password != the label, just to be sure :-P
 
 
This message posted from opensolaris.org

Lally Singh wrote:
> Looks great.. Any (long-term distant-future) plans of integrating this
 > with the Trusted Extensions for a real quick setup?

For you what would "integrated" with Trusted Extensions mean ?

They certainly work together just fine, but I want to better understand 
what you are actually looking for here.

Keeping in mind that often a TX label could have one or more ZFS 
datasets delegated to it.  It would likely have one for its root 
filesystem and one or more for the per label home dirs and data.

 > With a check to make sure the key''s password != the label,
 > just to be sure :-P

A generic password quality check would be a good idea to include.

-- 
Darren J Moffat

On 10/22/07, Darren J Moffat <darrenm at opensolaris.org>
wrote:
> Lally Singh wrote:
> > Looks great.. Any (long-term distant-future) plans of integrating this
>  > with the Trusted Extensions for a real quick setup?
>
> For you what would "integrated" with Trusted Extensions mean ?
>
> They certainly work together just fine, but I want to better understand
> what you are actually looking for here.
A few things come to mind:
 - Attaching a label to the zfs filesystem, so I can''t mount the FS in
an unlabeled or differently-labeled zone if I don''t want to.
(multiple labels for shared fs''s would be cool, too.)
 - Connecting the startup of the trusted zone (I''m still learning this
stuff, sorry if I''m completely off) to the mounting of the filesystem
-- I guess these two are similar, in enforcing access to the
restricted data to the restricted environment.  Perhaps requiring the
keys to the fs''s as the zone boots.
 - Straightforward setup to set them both up together.

On a portable or an easy-to-steal desktop, the trusted zone''s
don''t
help me much without an encrypted store for it.  Encrypted ZFS is
useful by itself, but trusted zones with a disk that can get stolen
needs encryption.

Optimally, that mind-boggling 2-line setup procedure for my ZFS setup
would be the model for setting up both a zfs encrypted store & a
trusted zone atop of it.
>
> Keeping in mind that often a TX label could have one or more ZFS
> datasets delegated to it.  It would likely have one for its root
> filesystem and one or more for the per label home dirs and data.
>
>  > With a check to make sure the key''s password != the label,
>  > just to be sure :-P
>
> A generic password quality check would be a good idea to include.

-- 
H. Lally Singh
Ph.D. Candidate, Computer Science
Virginia Tech

A few things come to mind:
* Attaching a label to the zfs filesystem, so I can''t mount the FS in
an unlabeled or differently-labeled zone if I don''t want to.
(multiple labels for shared fs''s would be cool, too.)
* Connecting the startup of the trusted zone (I''m still learning this
stuff, sorry if I''m completely off) to the mounting of the filesystem
-- I guess these two are similar, in enforcing access to the
restricted data to the restricted environment.  Perhaps requiring the
keys to the fs''s as the zone boots.
* Straightforward setup to set them both up together.

On a portable or an easy-to-steal desktop, the trusted zone''s
don''t
help me much without an encrypted store for it.  Encrypted ZFS is
useful by itself, but trusted zones with a disk that can get stolen
needs encryption.

Optimally, that mind-boggling 2-line setup procedure for my ZFS setup
would be the model for setting up both a zfs encrypted store & a
trusted zone atop of it.
 
 
This message posted from opensolaris.org