[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180914162142.GA734@sol.localdomain>
Date: Fri, 14 Sep 2018 09:21:43 -0700
From: Eric Biggers <ebiggers@...nel.org>
To: Colin Walters <walters@...bum.org>
Cc: linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org,
linux-f2fs-devel@...ts.sourceforge.net,
linux-integrity@...r.kernel.org, linux-fscrypt@...r.kernel.org,
linux-kernel@...r.kernel.org,
Mimi Zohar <zohar@...ux.vnet.ibm.com>,
Dmitry Kasatkin <dmitry.kasatkin@...il.com>,
Michael Halcrow <mhalcrow@...gle.com>,
Victor Hsieh <victorhsieh@...gle.com>
Subject: Re: [RFC PATCH 01/10] fs-verity: add setup code, UAPI, and Kconfig
Hi Colin,
On Fri, Sep 14, 2018 at 09:15:30AM -0400, Colin Walters wrote:
> On Sat, Aug 25, 2018, at 12:48 AM, Eric Biggers wrote:
> >
> > As Ted pointed out, only truncates are denied on fs-verity files, not other
> > metadata changes like chmod().
> >
> > Think of it this way: the purpose of fs-verity is *not* to make files immutable.
> > It's to hash them.
>
> Sorry for my unfamiliarity with Android internals but - in earlier discussion
> I believe it was mentioned that APK (zip files?) that are being targeted here, right?
>
> Now AIUI, Zip files have an internal header that contains e.g. the size and
> indexes into the internal files. So if someone added random data to the end
> of a zip file, nothing is going to end up actually reading it.
>
> However, there are file formats that use the size of the file reported by stat();
> at least OSTree does this with serializing GVariant. I'm sure there are others -
> I'd imagine at least some things parsing ELF do this?
> In such a case, we really want to deny appending to the file as well.
>
> Unless there's some mechanism to deny applications reading not-verified
> data?
>
> And "hidden" data after fs-verity protected files would be a nice place
> for persistent malware to hide.
>
> Does anyone know of a use case for appending to a fs-verity file?
>
> The slides here:
> https://events.linuxfoundation.org/wp-content/uploads/2017/11/fs-verify_Mike-Halcrow_Eric-Biggers.pdf
> even say "File becomes read-only!"
>
> If not, then here's a strawman: Require that at FS_IOC_ENABLE_VERITY time
> the file does not have any +w bits set (and I guess no ACLs that do so...
> that may get ugly).
>
> I think that would make it easier to later factor out a "_CONTENTS_IMMUTABLE"
> flag.
>
After the verity bit is enabled, the verity metadata is not visible to
userspace. Yes, that means i_size is adjusted too. Also all contents
modifications are denied, including appends.
- Eric
Powered by blists - more mailing lists