linux-ext4 - Re: [PATCH 3/4] generic: test encrypted file access

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-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 22 Nov 2016 08:23:48 +1100
From:   Dave Chinner <david@...morbit.com>
To:     Eric Biggers <ebiggers@...gle.com>
Cc:     fstests@...r.kernel.org, linux-ext4@...r.kernel.org,
        "Theodore Y . Ts'o" <tytso@....edu>,
        Jaegeuk Kim <jaegeuk@...nel.org>,
        Richard Weinberger <richard@....at>,
        David Gstir <david@...ma-star.at>
Subject: Re: [PATCH 3/4] generic: test encrypted file access

On Mon, Nov 21, 2016 at 11:23:30AM -0800, Eric Biggers wrote:
> On Mon, Nov 21, 2016 at 09:31:51AM +1100, Dave Chinner wrote:
> > 
> > But, then again, why wouldn't you just dump:
> > 
> > ls -lR edir |_filter_scratch
> > 
> > to the golden output file to confirm everything is exactly as you
> > expect it to be in the encrypted directory? It'll catch un-encrypted
> > names, wrong subdir depth, etc.
> > 
> 
> This won't work because the encrypted filenames are unpredictable.  The
> filenames in a directory are encrypted by a key unique to that directory which
> is derived from the designated keyring key and a per-inode nonce.  Nonces are
> generated randomly by the kernel, so the per-inode encryption keys cannot be
> predicted even if you were to put a fixed key into the keyring rather than a
> random one.  This is by design because for confidentiality reasons, the same
> filename in different directories must not encrypt to the same ciphertext.  A
> similar argument applies to the contents of regular files and to symlink
> targets.
> 
> (Yes, I should make this clear in a comment in the test.)

Please do! :P

> 
> > 
> > > +cat $(find edir -maxdepth 1 -type f | head -1) 2>tmp
> > > +if ! egrep -q 'Required key not available' tmp; then
> > > +	echo "Reading encrypted file w/o key didn't fail with ENOKEY"
> > > +	cat tmp
> > > +	exit 1
> > > +fi
> > 
> > md5sum `find edir -maxdepth 1 -type f | head -1` | _filter_scratch
> > 
> > You'll either get a md5sum of the data or an error message
> > in the golden output. The wrong one will trigger a failure.
> 
> This won't quite work because the encrypted filename cannot be predicted, but it
> would work if the filename were to be filtered out.

*nod*. cut or awk will do that quickly and easily, and can replace
the _filter_scratch call...

Cheers,

Dave.

-- 
Dave Chinner
david@...morbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html