linux-ext4 - backup/restore of fscrypt files

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <D1AD7D55-94D6-4C19-96B4-BAD0FD33CF49@dilger.ca>
Date:   Thu, 26 Nov 2020 00:12:26 -0700
From:   Andreas Dilger <adilger@...ger.ca>
To:     Eric Biggers <ebiggers@...nel.org>, Theodore Ts'o <tytso@....edu>
Cc:     linux-fscrypt@...r.kernel.org,
        Ext4 Developers List <linux-ext4@...r.kernel.org>,
        linux-f2fs-devel@...ts.sourceforge.net,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Sebastien Buisson <sbuisson@....com>
Subject: backup/restore of fscrypt files

Currently it is not possible to do backup/restore of fscrypted files without the
encryption key for a number of reasons.  However, it is desirable to be able to
backup/restore filesystems with encrypted files for numerous reasons.

My understanding is that there are two significant obstacles for this to work:
- the file size reported to userspace for an encrypted file is the "real" file size,
  but there is data stored beyond "i_size" that is required for decrypting the file
- the per-inode 16-byte nonce that would need to be backed up and restored for
  later decryption to be possible

I'm wondering if it makes sense for stat() to report the size rounded up to the end
of the encryption block for encrypted files, and then report the "real" size and
nonce in virtual xattrs (e.g. "trusted.fscrypt_size" and "trusted.fscrypt_nonce")
so that encrypted files can be backed up and restored using normal utilities like
tar and rsync if the xattrs are also copied.

A (small) added benefit of rounding the size of encrypted files up to the end of the
encryption block is that it makes fingerprinting of files by their size a bit harder.
Changing the size returned by stat() is not (IMHO) problematic, since it is not
currently possible to directly read encrypted files without the key anyway.

The use of "trusted" xattrs would limit the backup/restore of encrypted files to
privileged users.  We could use "user" xattrs to allow backup by non-root users, but
that would re-expose the real file size to userspace (not worse than today), and
would corrupt the file if the size or nonce xattrs were modified by the user.

It isn't clear whether there is a huge benefit of users to be able to backup/restore
their own files while encrypted.  For single-user systems, the user will have root
access anyway, while administrators of multi-user systems need privileged access for
shared filesystems backup/restore anyway.

I'm probably missing some issues here, but hopefully this isn't an intractable problem.

Cheers, Andreas

Download attachment "signature.asc" of type "application/pgp-signature" (874 bytes)