On Thu, Jan 22, 2004 at 06:41:12PM -0700, Frank Sorenson wrote:
> On Thu, 22 Jan 2004, Michael Halcrow said:
> > Any other requirements?  Don't be afraid to get creative.  :-)
> 
> Some thoughts:
> 
> - Encrypted filesystems over a remote link.  Make it look like one
> seamless filesystem, so that I don't care whether the data is local or
> remote.  Something like sshfs, but with the data actually encrypted from
> the disk all the way to my machine.

Sounds more like a contortion of AFS.  :-)  I don't know quite what to
think of FUSE and LUFS and the sort yet, and I fear that something
like you describe here will either require that, or a kernel patch.
If you can see an obvious way for the existing VFS+userland NFS
marriage to work that out, I'm all ears.

> - Encrypted filesystem should allow versions, offline, snapshots,
> file/data recovery, ACL's, and secure delete (shred).

Unfortunately, one of the project requirements is that the encryption
must take place via a layer on top of another filesystem, and
filesytems like ext3 preclude shredding.  I can make the shredding
process transparent for those filesystems that support it though.

Versioning and snapshots... hmmmm... I suppose I could implement that
with some CVS-like magic.  That definitely won't make it in on the
first cut, but I'll keep that in the back of my mind for future
enhancements.

> - Key located on memory card or other physical device

That's a popular request.  That will come with PAM support:

http://www.sig11.org/~al/pam_usb/

> - Add time-based ACLs.  Not encrypted filesystem-specific, but sometimes I 
> want to allow access for a certain period of time.  Perhaps implemented 
> with one-time pad...

I wonder if SE Linux policies can describe something like this?

> - Per-file/per-directory multi-layer encryption, where I can allow 
> specific users/groups access to portions of the data

Portions of the same *file*?  What granularity are you speaking of
here?  I think I can get this down to the per-file level without too
much of a problem, but sub-file starts to get messy (it may still be
possible).

Good comments.  Keep 'em coming, y'all!

Mike
.___________________________________________________________________.
                         Michael A. Halcrow                          
       Security Software Engineer, IBM Linux Technology Center       
GnuPG Fingerprint: 05B5 08A8 713A 64C1 D35D  2371 2D3C FDDA 3EB6 601D

GNU/Linux: Because a computer is a terrible thing to waste. 

Attachment: pgp00000.pgp
Description: PGP signature

____________________
BYU Unix Users Group 
http://uug.byu.edu/ 
___________________________________________________________________
List Info: http://uug.byu.edu/cgi-bin/mailman/listinfo/uug-list

Reply via email to