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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ