linux-ext4 - Re: [PATCH] ext4: forbid encrypting root directory

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20170616175457.GA20865@gmail.com>
Date:   Fri, 16 Jun 2017 10:54:57 -0700
From:   Eric Biggers <ebiggers3@...il.com>
To:     Andreas Dilger <adilger@...ger.ca>
Cc:     linux-ext4 <linux-ext4@...r.kernel.org>,
        linux-fscrypt@...r.kernel.org, Theodore Ts'o <tytso@....edu>,
        Jaegeuk Kim <jaegeuk@...nel.org>,
        Eric Biggers <ebiggers@...gle.com>
Subject: Re: [PATCH] ext4: forbid encrypting root directory

On Wed, Jun 14, 2017 at 08:02:05PM -0600, Andreas Dilger wrote:
> >> 
> >> What about a special case to handle an unencrypted lost+found inode?
> >> 
> >> There was also a patch series a while ago to explicitly add lost+found
> >> into the superblock so that it could be found even if the root directory
> >> was corrupted, and to allow flexibility in whether it is always shown in
> >> the root directory or not (e.g. allowing ".lost+found" or similar).
> > 
> > It could be done if the lost+found inode was not linked to from any directory
> > and instead had its inode number stored in the superblock so that e2fsck could
> > still find it.  However, if e2fsck put files in a lost+found directory that
> > doesn't exist in the filesystem directory structure, how would users retrieve
> > those files?  Would users be required to run a special e2fsprogs command to
> > list/read/delete the files in lost+found?
> 
> I was thinking that readdir on the root inode could insert the "lost+found"
> or ".lost+found" entry dynamically,

I think this is possible, but not trivial.  It's not just readdir; ->lookup()
would also have to special-case lookups of "lost+found", and we'd have to
override the fscrypt_permitted_context() check.  It would also have to be a
RO_COMPAT filesystem feature, lest an unaware ext4 driver or e2fsprogs create a
lost+found directory which would then be ambiguous with the "real" one.

> or (a bit less pleasant) is to add a
> special case that this entry is just never encrypted (could compare the
> inode number to the one stored in the superblock, instead of comparing names)?

I think that would be similarly difficult, as it would still require special
logic in readdir and ->lookup(), and would still require a RO_COMPAT filesystem
feature.

Either way, not all filesystems will have the implicit "lost+found" directory
feature, so we're still going to need to forbid encrypting the root directory on
some filesystems anyway.

Eric