Messages in this thread | | | Date | Thu, 26 Aug 2004 08:53:19 -0500 | From | Michael Halcrow <> | Subject | Re: silent semantic changes with reiser4 |
| |
If I may chime in here...
On Wed, Aug 25, 2004 at 01:22:55PM -0700, Linus Torvalds wrote: > On Wed, 25 Aug 2004, Christoph Hellwig wrote: > > > > For one thing _I_ didn't decide about xattrs anyway. And I still > > haven't seen a design from you on -fsdevel how you try to solve > > the problems with files as directories. > > Hey, files-as-directories are one of my pet things, so I have to > side with Hans on this one. I think it just makes sense. A hell of a > lot more sense than xattrs, anyway, since it allows scripts etc > standard tools to touch the attributes. > > It's the UNIX way.
This is an issue that directly affects work I am doing in extended cryptfs:
http://www.linuxsymposium.org/2004/view_abstract.php?content_key=55 http://halcrow.us/~mhalcrow/ols2004.pdf http://halcrow.us/~mhalcrow/ols_cryptfs.sxi
The basic idea is that the cryptographic context for every file is correlated with the individual file via xattr's. A file is a unit of data that should, as it stands, contain all the information requisite for the encrypting filesystem layer to transparently decrypt (and encrypt, when the file is written to). This allows for a key->file granularity, as opposed to a key->block device (dm-crypt) or a key->mount point (CFS) granularity.
My grand vision is to have a policy that determines whether or not the encrypted version of the file or the decrypted version of the file is read, dependent on whether or not the file is leaving the security domain (the storage device under the control of the currently running kernel). For example, if the ``cp'' command is copying a file from a filesystem mounted from /dev/hda1 to a filesystem mounted from /dev/fd0, then the policy would indicate that (unless otherwise noted in the .cryptfsrc file in the root of the filesystem mounted from /dev/fd0, which might also contain the default security context for that filesystem or directory - like whose public keys should be used to encrypt the symmetric key for data) the file is leaving the security domain, and the encrypted contents of the file should be given to cp. Same with mutt reading an email attachment (as opposed to, say, .muttrc, where, more likely than not, the unencrypted version is wanted).
The goal is to enable an ``encrypted by default'' policy, in which files on the storage devices are independent encrypted units that remain encrypted until an application that actually needs to see the decrypted contents opens them. Then the encryption and decryption is done transparently by the fs layer, as long as the user has the right keys. Extended attributes seem like a natural way to store this context.
Once you consider that you can have a crypto context for each file, you can start doing other neat tricks, like keyed hashes over extents within the file, to allow for dynamic integrity verification during the read. If an offset of 1.5 gigabytes into a 2-gigabyte has been tampered with, then that tampering will be caught when that portion of the file is read; you don't have to verify the hash of the entire 2-gigabyte file at the time of the open. Of course, this would very rapidly overrun the available xattr storage size. And so to realistically implement something like this, some new underlying file format is in order.
In any case, the issue of userspace applications supporting extended attributes is key to the viability of this approach. If cp, uuencode, tar, or what not do not preserve the extended attributes, then the crypto context is lost, and the file is unreadable. So the $64,000 question is, just how committed is the community to this whole concept of extended attributes? From this point, should I assume that good xattr support is forthcoming, or should I abandon the idea of using xattr's for this altogether?
One solution I've been kicking around is to make cryptfs GnuPG-compatible. Not only would this eliminate the need to store some of the crypto context in the xattr set, but it would also preserve the crypto context with apps that don't know about xattr's, and it would be possible for users who are not running cryptfs to read the files with gpg. Keyed hashes over extents would be doable if GnuPG allowed for opaque data blobs in the file that gpg would just ignore when decrypting the file (gnupg-dev list had technical issues last time I tried to post these ideas to it - any gpg guys around that can comment on this?).
> I never liked the xattr stuff. It makes little sense, and is totally > useless for 99.9999% of everything. I still don't see the point of it, > except for samba. Ugly.
If xattr's wind up getting supported by a certain critical mass of applications, then they are somewhat useful for me, although, as currently implemented, are insufficient for what I really need (keyed hashes over extents require too much space).
BTW, early this week I migrated cryptfs over to use David Howell's new keyring, which is working out nicely.
Mike .___________________________________________________________________. Michael A. Halcrow Security Software Engineer, IBM Linux Technology Center GnuPG Fingerprint: 05B5 08A8 713A 64C1 D35D 2371 2D3C FDDA 3EB6 601D[unhandled content-type:application/pgp-signature] | |