linux-fscrypt.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Boris Burkov <boris@bur.io>
Cc: linux-fscrypt@vger.kernel.org, kernel-team@fb.com
Subject: Re: [RFC PATCH] fsverity: add enable sysctl
Date: Mon, 13 Sep 2021 20:14:02 -0700	[thread overview]
Message-ID: <YUATekKOECWznxl8@sol.localdomain> (raw)
In-Reply-To: <ebc9c81c31119e0ce8f810c5729b42eef4c5c3af.1631560857.git.boris@bur.io>

On Mon, Sep 13, 2021 at 05:37:15PM -0700, Boris Burkov wrote:
> At Facebook, we would find a global killswitch sysctl reassuring while
> rolling fs-verity out widely. i.e., we could run it in a logging mode
> for a while, measure how it's doing, then fully enable it later.
> 
> However, I feel that "let root turn off verity" seems pretty sketchy, so
> I was hoping to ask for some feedback on it.
> 
> I had another idea of making it per-file sort of like MODE_LOGGING in
> dm-verity. I could add a mode to the ioctl args, and perhaps a new ioctl
> for getting/setting the mode?
> 
> The rest is the commit message from the patch I originally wrote:
> 
> 
> Add a sysctl killswitch for verity:
> 0: verity has no effect, even if configured or used
> 1: verity is in "audit" mode, only log on failures
> 2: verity fully enabled; the behavior before this patch
> 
> This also precipitated re-organizing sysctls for verity as previously
> the only sysctl was for signatures and setting up the sysctl was coupled
> with the signature logic.
> 
> Signed-off-by: Boris Burkov <boris@bur.io>

I don't think there's any security problem with having this root-only sysctl.
The fs.verity.require_signatures sysctl already works that way.  We aren't
trying to protect against root, unless you've set up your system properly with
SELinux, in which case fine-grained access control of sysctls is available.

The mode 0 is the one I like the least, as it makes some ad-hoc changes like
making the fs-verity ioctls fail with -EOPNOTSUPP.  If userspace doesn't want to
use those ioctls, shouldn't it just not use those ioctls?

It might help if you elaborated on what sort of problems you are trying to plan
for.  One concern that was raised on Android was that on low-end flash storage,
files can have bit-flips that would normally be "benign" but would cause errors
if fs-verity detects them.  Falling back to your mode 1 (logging-only) would be
sufficient if that happened and caused problems.  So I am wondering more what
the purpose of mode 0 would be; it seems it might be overkill, and an
"enforcing" boolean equivalent to your modes 1 and 2 might be sufficient?

Did you also consider a filesystem mount option?  I guess the sysctl makes sense
especially since we already have the require_signatures one, but you probably
should CC this to the filesystem mailing lists (ext4, f2fs, and btrfs) in case
other people have opinions on this.

- Eric

  reply	other threads:[~2021-09-14  3:14 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-14  0:37 [RFC PATCH] fsverity: add enable sysctl Boris Burkov
2021-09-14  3:14 ` Eric Biggers [this message]
2021-09-14 19:11   ` Boris Burkov
2021-09-15  0:16     ` Eric Biggers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YUATekKOECWznxl8@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=boris@bur.io \
    --cc=kernel-team@fb.com \
    --cc=linux-fscrypt@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).