linux-kernel - Re: [PATCH] ubifs: Return -ENOKEY from rename if encryption keys are missing

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:   Wed, 26 Apr 2017 13:48:10 +0200
From:   David Oberhollenzer <david.oberhollenzer@...ma-star.at>
To:     Eric Biggers <ebiggers@...gle.com>,
        Richard Weinberger <richard@....at>
Cc:     linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-fscrypt@...r.kernel.org, david@...ma-star.at
Subject: Re: [PATCH] ubifs: Return -ENOKEY from rename if encryption keys are
 missing

On 04/25/2017 07:54 PM, Eric Biggers wrote:
> Did you test that this change actually does anything?  Unlike ext4 and f2fs,
> ubifs calls fscrypt_setup_filename() from its rename methods rather than through
> a helper function ${FS}_find_entry().  Therefore it's able to pass in lookup=0,
> which means that the key is required.  So it should already be failing with
> ENOKEY.  You can verify this by running xfstests generic/419.

Actually, running xfstests was how this cropped up in the first place.

The UBIFS rename and xrename functions allready call
fscrypt_setup_filename with lookup=0, however there are other tests
before that call and moving them around causes generic/419 to fail
at a different place where EPERM was expected.

Therefore I concluded that the safest way to fix this might be to
simply copy the way the checks are handled in ext4.

With recent xfstests + UBIFS support patch, after applying this patch,
generic/419 passes.

David