linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Christian Brauner <brauner@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>,
	Dmitry Vyukov <dvyukov@google.com>, Jan Kara <jack@suse.cz>,
	Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org, Ted Tso <tytso@mit.edu>,
	yebin <yebin@huaweicloud.com>,
	linux-fsdevel@vger.kernel.org,
	syzkaller <syzkaller@googlegroups.com>
Subject: Re: [PATCH] block: Add config option to not allow writing to mounted devices
Date: Wed, 14 Jun 2023 12:36:54 +0200	[thread overview]
Message-ID: <20230614103654.ydiosiv6ptljwd7i@quack3> (raw)
In-Reply-To: <20230614-anstalt-gepfercht-affd490e6544@brauner>

On Wed 14-06-23 10:18:16, Christian Brauner wrote:
> On Wed, Jun 14, 2023 at 12:17:26AM -0700, Christoph Hellwig wrote:
> > On Tue, Jun 13, 2023 at 08:09:14AM +0200, Dmitry Vyukov wrote:
> > > I don't question there are use cases for the flag, but there are use
> > > cases for the config as well.
> > > 
> > > Some distros may want a guarantee that this does not happen as it
> > > compromises lockdown and kernel integrity (on par with unsigned module
> > > loading).
> > > For fuzzing systems it also may be hard to ensure fine-grained
> > > argument constraints, it's much easier and more reliable to prohibit
> > > it on config level.
> > 
> > I'm fine with a config option enforcing write blocking for any
> > BLK_OPEN_EXCL open.  Maybe the way to it is to:
> > 
> >  a) have an option to prevent any writes to exclusive openers, including
> >     a run-time version to enable it
> 
> I really would wish we don't make this runtime configurable. Build time
> and boot time yes but toggling it at runtime makes this already a lot
> less interesting.

I see your point from security POV. But if you are say a desktop (or even
server) user you may need to say resize your LVM or add partition to your
disk or install grub2 into boot sector of your partition. In all these
cases you need write access to a block device that is exclusively claimed
by someone else. Do you mandate reboot in permissive mode for all these
cases? Realistically that means such users just won't bother with the
feature and leave it disabled all the time. I'm OK with such outcome but I
wanted to point out this "no protection change after boot" policy noticably
restricts number of systems where this is applicable.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

  reply	other threads:[~2023-06-14 10:37 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-12 16:16 [PATCH] block: Add config option to not allow writing to mounted devices Jan Kara
2023-06-12 16:25 ` Jan Kara
2023-06-12 17:39   ` Bart Van Assche
2023-06-12 17:47     ` Theodore Ts'o
2023-06-12 18:52     ` Colin Walters
2023-06-13 11:34       ` Jan Kara
2023-06-14  1:55         ` Darrick J. Wong
2023-06-14  7:14           ` Christoph Hellwig
2023-06-14  7:05         ` Christian Brauner
2023-06-14  7:07           ` Christoph Hellwig
2023-06-14  7:10         ` Christoph Hellwig
2023-06-14 10:12           ` Jan Kara
2023-06-14 14:30             ` Christoph Hellwig
2023-06-14 14:46             ` Matthew Wilcox
2023-06-13  4:56 ` kernel test robot
2023-06-13  5:10 ` Christoph Hellwig
2023-06-13  6:09   ` Dmitry Vyukov
2023-06-14  7:17     ` Christoph Hellwig
2023-06-14  8:18       ` Christian Brauner
2023-06-14 10:36         ` Jan Kara [this message]
2023-06-14 12:48           ` Christian Brauner
2023-06-15 14:39             ` Jan Kara
2023-06-14 14:31         ` Christoph Hellwig
2023-06-13 20:56   ` Jan Kara
2023-06-14  7:20     ` Christoph Hellwig
2023-06-20 10:41       ` Jan Kara
2023-06-20 11:29         ` Christoph Hellwig
2023-06-14  7:35     ` Christian Brauner
2023-06-13  6:49 ` Dmitry Vyukov
2023-06-13 19:22   ` Theodore Ts'o
2023-06-14  0:26   ` Dave Chinner
2023-06-14  2:04   ` Darrick J. Wong
2023-06-14  2:57     ` Theodore Ts'o
2023-06-14 12:27     ` Dmitry Vyukov
2023-06-14 23:38       ` Dave Chinner
2023-06-15  9:14         ` Dmitry Vyukov
2023-06-18 23:35           ` Dave Chinner

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=20230614103654.ydiosiv6ptljwd7i@quack3 \
    --to=jack@suse.cz \
    --cc=axboe@kernel.dk \
    --cc=brauner@kernel.org \
    --cc=dvyukov@google.com \
    --cc=hch@infradead.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=syzkaller@googlegroups.com \
    --cc=tytso@mit.edu \
    --cc=yebin@huaweicloud.com \
    /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).