From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Fri, 14 Sep 2018 09:21:43 -0700 From: Eric Biggers Subject: Re: [RFC PATCH 01/10] fs-verity: add setup code, UAPI, and Kconfig Message-ID: <20180914162142.GA734@sol.localdomain> References: <20180824161642.1144-1-ebiggers@kernel.org> <20180824161642.1144-2-ebiggers@kernel.org> <1535132549.2855027.1485213752.129E3334@webmail.messagingengine.com> <20180825044852.GB726@sol.localdomain> <1536930930.1003187.1508104496.6465C44D@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1536930930.1003187.1508104496.6465C44D@webmail.messagingengine.com> Sender: linux-integrity-owner@vger.kernel.org To: Colin Walters Cc: linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-integrity@vger.kernel.org, linux-fscrypt@vger.kernel.org, linux-kernel@vger.kernel.org, Mimi Zohar , Dmitry Kasatkin , Michael Halcrow , Victor Hsieh List-ID: 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