On Thu, Jan 22, 2004 at 01:06:31PM -0700, Stuart Jansen wrote: > On Thu, 2004-01-22 at 11:31, Michael Halcrow wrote: > > If you could have any feature that you wanted in an encrypted > > filesystem, what would it be? > > I want an easy and clean API to discover if a filesystem is encrypted. I > don't consider ioctl to be easy or clean. Bonus points for making it > portable and easy to fit into a posix system.
How about if it's all in userland, implemented via RPC, like an NFS
server daemon? That's certainly POSIX for ya. CFS is that.
> I want is something my mother could use to keep her files safe.
Oh, the *mother* test. Uh-oh...
> If the box is her's, I want to be able to setup an encrypted
> filesystem during install.
Out of my control, unfortunately. Gotta play politics with SuSE for
that trick.
> Basic stuff like mounting should have a friendly GUI with
> prompt. But my mother shouldn't have to know what mounting is.
That's Gnome's job. :-)
> If the filesystem isn't critical, the system shouldn't block waiting
> for a password. Rather, if it has been configured to be mounted on
> boot but a password isn't entered during the boot process, something
> like D-Bus should be used to request the password the first time she
> tries to access the encrypted filesystem.
How about using PAM for authentication, and having processes carry
credentials? Or how about a daemon that manages authentication
states, and decisions about encryption or decryption must go by what
the auth daemon says? Or maybe a new coorporative LSM that jives with
the daemon?
> I want something that users can use without administrator
> intervention.
CFS does this. :-)
> A user should be able to encrypt their entire home directory, or a
> directory underneath it.
Again, CFS.
> Any program she runs should be able to interact with that directory
> as if it were normal.
See CFS.
> See the comment about prompting for a password the first time the
> directory is used.
That would be... CFS.
> My mother shouldn't have to worry about permissions. If she has an
> encrypted directory, only her programs should be able to see it's
> contents. Not even root should be able to see it necessarily.
Oops - that's *not* CFS. But it could be CFS+SELinux. Or CFS+ACL's.
> She should be able to associate other users (with passwords
> different from her own) with the encrypted directory.
That's on my list.
> This could possibly be accomplished like this: My mother has a
> public/private key pair that is password protected. Possibly stored
> in something like /etc/shadow. The directory is encrypted with a
> symmetric key. Near the beginning of the "directory" is a copy of
> the symmetric key for the directory encrypted with her public
> key. After my mother is prompted for her password (seperate from her
> login password, to reinforce the fact that this is a higher security
> level), the private key is decrypted and used to get the symmetric
> key. When she decides to give me access, she encrypts the symmetric
> key (which she already knows as a result of the mount) with my
> public key and appends it to the ACL for the directory.
This is an interesting approach, but it has its drawbacks (i.e.,
messy revocation, metafiles strewn about). I will be looking very
carefully at using PAM for this kind of footwork.
> Encrypted directories should look just like files before being
> mounted so that that can be easily transferred between systems. It
> should be possible to store them on systems that knows nothing about
> the format without losing any data. (No hiding stuff in forks.)
Metadata will be in Extended Attributes, with the files. As long as
you use star rather than tar, that should work. ;-) And I don't
think I'm going to go with the whole ``encrypted directory'' approach;
encryption will be on a per-file basis.
> It should be easy to transfer public/private key pairs between
> systems without knowing about dot directories, etc. A nice "I'm
> Moving" gui should be available. It should be possible to associate
> multiple key pairs with an account. Because this is going to have to
> be kernel level, there should be a _very_ standard location like
> /etc/passwd for the key pairs.
All the metadata necessary for an authenticated user to know how to
decrypt a file will be stored *with* each individual file as Extended
Attributes. As long as it is passing through the quasi-NFS server,
the daemon will be able to figure out what to do.
> If multiple key pairs are registered, it should be easy to tell which
> one I'm unlocking so I can remember the password I chose for it.
Authentication will not be limited to passwords, since I would like
PAM to be involved. For password use, this seems like a good idea.
But I would like to give the user the option to distance passwords
from files, if he so chooses (think: USB thingy for a set of files,
another USB thingy for another set of files).
> Of course, no sensitive data should ever be swapped. To prevent
> pinning giant pages of data, only the symmetric keys should be on
> non-swappable pages. I shouldn't have to pay a performance hit for
> most of the disk cache being encrypted. (Okay, so maybe I'm dreaming
> a little too big now.)
I thought you said that you wanted it portable. This requires a
kernel patch. I will vehemently resist any and all attempts to patch
the kernel, as will the kernel maintainers. :-)
Mike
.___________________________________________________________________.
Michael A. Halcrow
Security Software Engineer, IBM Linux Technology Center
GnuPG Fingerprint: 05B5 08A8 713A 64C1 D35D 2371 2D3C FDDA 3EB6 601D
Fight mandatory .signature truncation! Call
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
