Re: [RFC PATCH 01/10] fs-verity: add setup code, UAPI, and Kconfig

[Eric Biggers]

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