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
