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
| ||
|
Message-ID: <CAKOZuesHHSRCzQEtGEQbm7v7j53hAjkJq-8Pgcyk+M40o-ia0g@mail.gmail.com> Date: Fri, 4 Jan 2019 12:41:24 -0800 From: Daniel Colascione <dancol@...gle.com> To: "Theodore Y. Ts'o" <tytso@....edu>, Matthew Wilcox <willy@...radead.org>, Linus Torvalds <torvalds@...ux-foundation.org>, Christoph Hellwig <hch@...radead.org>, Dave Chinner <david@...morbit.com>, "Darrick J. Wong" <darrick.wong@...cle.com>, Eric Biggers <ebiggers@...nel.org>, linux-fscrypt@...r.kernel.org, linux-fsdevel <linux-fsdevel@...r.kernel.org>, linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net, linux-integrity@...r.kernel.org, Linux List Kernel Mailing <linux-kernel@...r.kernel.org>, Jaegeuk Kim <jaegeuk@...nel.org>, Victor Hsieh <victorhsieh@...gle.com>, Chandan Rajendra <chandan@...ux.vnet.ibm.com> Subject: Re: [PATCH v2 01/12] fs-verity: add a documentation file On Sat, Dec 22, 2018 at 8:46 PM Theodore Y. Ts'o <tytso@....edu> wrote: > > On Sat, Dec 22, 2018 at 08:10:07PM -0800, Matthew Wilcox wrote: > > Pretty much every file format has the ability to put arbitrary blocks > > of information into a file somewhere the tools which don't know about > > it will skip it. For example, ZIP "includes an extra field facility > > within file headers, which can be used to store extra data not defined > > by existing ZIP specifications, and which allow compliant archivers that > > do not recognize the fields to safely skip them. Header IDs 0–31 are > > reserved for use by PKWARE. The remaining IDs can be used by third-party > > vendors for proprietary usage. " (Wikipedia) > > > > ELF, PNG, PDF and many other formats have the ability to put data > > _somewhere_. It might not be at the tail of the file, but there's > > somewhere to do it. > > > > (I appreciate this isn't what Linus is asking for, but I'm pointing out > > that this is by no means as intractable as you make it sound.) > > That design would require the fs-verity code to know the type of eacho > file, and where to find the in-band Merkle tree for each file type > that we wanted to support. And if you wanted to use fs-verity to > protect a sudoers text configuration file (for example), we'd have to > teach sudo how to ignore the userspace visible Merkle tree. I'm pretty late to the game, but I just want to bring up one approach that I'm not sure people have previously considered. You can't put the verification blob in an xattr due to xattr size limits, but you *can* put a filename in an xattr. What if, at open time, fs-verity looked for a specially-named xattr attached to a file, resolved that name like a symlink target, opened the pointed-to file, and just used *that* as the authentication blob? It'd also be possible to teach unlink to delete the pointed-to file when the pointer file is deleted --- sort of like a simple and stupid kind of data fork. For example, if you wanted to secure /usr/bin/emacs, you could set an security.fsverify.verification_file xattr (in the system namespace because the xattr has special semantics) to "/.verification-blobs/@usr@bin@...cs.hashtree" or something like that. Then, open(2) on /usr/bin/emacs would, internally to VFS, also open /.verification-blobs/@usr@bin@...cs.hashtree and read verification data from it, transparently to both users and the underlying filesystem. If someone deleted /usr/bin/emacs, VFS would automatically delete /.verification-blobs/@usr@bin@...cs.hashtree. If /.verification-blobs/@usr@bin@...cs.hashtree didn't exist at time of open(2) of /usr/bin/emacs, or couldn't be opened for whatever reason, the open(2) of /usr/bin/emacs would fail. ISTM that a scheme like this would give you some of the advantages of jumbo xattrs, but with much less implementation complexity. If someone's proposed something like this before, sorry for the noise.
Powered by blists - more mailing lists