From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C8F17FA372C for ; Fri, 8 Nov 2019 19:18:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A10CF2087E for ; Fri, 8 Nov 2019 19:18:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="Mx+u0nsl" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389507AbfKHTS5 (ORCPT ); Fri, 8 Nov 2019 14:18:57 -0500 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]:51519 "EHLO wout2-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387560AbfKHTSy (ORCPT ); Fri, 8 Nov 2019 14:18:54 -0500 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 997BB187 for ; Fri, 8 Nov 2019 14:18:53 -0500 (EST) Received: from imap37 ([10.202.2.87]) by compute3.internal (MEProxy); Fri, 08 Nov 2019 14:18:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=mx2RdF/2L93Izis0x1VdtxMgJourF 7t7Gts98N1YvKE=; b=Mx+u0nsl07bbVZb0ZhX3mdxdlMhJFpEm2WpXPXQSbL8qK K/DCfjXIjNHCfq7WceD7RYyrNRWkItsCVGT93J/EZ9CZZRhZ1QKdqzYi1tieBR2H BRIWF0g5JRssumjqx/0I8VIaH3/diNAPlpYGuf3TNqcBVoFG/h+AfmhCXu3Oii5p YENFDgjtz+clQK5aQIfTgcJElaWCVccJ+9Oty2BNoHisrCxHTpyuvE4AJOJ86a/+ PgdM7fs0DQblxhEf+a8KGPxA3xbEughiIcJDBbh+RBhnMbrTOzXvR0Cl23RPo0WQ Hu5B+sgVt96+3jZII0hY93ratLU5mlHPezueWNqgg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddvuddguddvhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesthdtre dtreertdenucfhrhhomhepfdevohhlihhnucghrghlthgvrhhsfdcuoeifrghlthgvrhhs sehvvghrsghumhdrohhrgheqnecuffhomhgrihhnpehlfihnrdhnvghtnecurfgrrhgrmh epmhgrihhlfhhrohhmpeifrghlthgvrhhssehvvghrsghumhdrohhrghenucevlhhushht vghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E66AE684005F; Fri, 8 Nov 2019 14:18:52 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1 Mime-Version: 1.0 Message-Id: <696354c2-5d7a-4f37-93d2-9a58845ad22d@www.fastmail.com> Date: Fri, 08 Nov 2019 14:18:32 -0500 From: "Colin Walters" To: linux-fscrypt@vger.kernel.org Subject: Some questions/thoughts on fs-verity Content-Type: text/plain Sender: linux-fscrypt-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fscrypt@vger.kernel.org It's clear that the Linux kernel is widely deployed with things like dm-verity devices where the user of the device isn't root. There are great security properties from this in ensuring malicious code (compromised apps/OS) can't persist, and what Google is doing with ChromeOS/Android is a good example. However, for cases where the user *is* root (or, like me as an OS vendor trying to support an OS where the user can be root), dm-verity comes with a whole host of restrictions and issues. This was noted in the earlier fs-verity discussions. Among other ones, simply trying to commit to a partition size beyond which the trusted OS cannot grow is seriously ugly. Another example here is with ostree (or other filesystem-level tools) it's easy to have *three* images (or really N) so that while you're downloading updates you don't lose your rollback, etc. I'm excited about the potential of fs-verity because it's so much more *flexible* - leaving aside the base OS case for a second - for example fs-verity is even available to unprivileged users by default, so if the admin has at least enabled the `verity` flag, if a user wanted to they could enable fs-verity for e.g. their `~/.bashrc`. That's neat! However, this gets into some questions I have around the security properties of fs-verity because - it only covers file contents. There are many problems from this: - Verifying directories and symlinks is really desirable too; take e.g. /etc/systemd/system - I want to verify not just that the unit files there are valid, but also that there's no malicious ones. - Being able to e.g. `chown root:root` `chmod u+s` a fs-verity protected binary is...not desired. - Finally, taking the scenario of a malicious code that has gained CAP_SYS_ADMIN and the ability to write to raw block devices, it seems to me that the discussions around "untrusted filesystems" (https://lwn.net/Articles/755593/) come to the fore. In contrast because dm-verity is sealing up *everything* at the fs level, all of the above are avoided. But it's obviously far less flexible... (This discussion of course mirrors fs-crypt versus dm-crypt too) I guess my concrete question here is: Are there any plans around extending fs-verity to address any of this? Which I know given the current developers probably mostly boils down to a future Android/ChromeOS architecture question, but I think fs-verity has the potential to be used beyond just that if it isn't already. Would love to discuss with any other distributions/update system developers etc. that are also looking at fs-verity!