lkml.org 
[lkml]   [2004]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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]
    \
     
     \ /
      Last update: 2005-03-22 14:05    [W:0.053 / U:58.364 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site