linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Jan Kara <jack@suse.cz>
Cc: Colin Walters <walters@verbum.org>,
	Bart Van Assche <bvanassche@acm.org>,
	Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org,
	Christoph Hellwig <hch@infradead.org>,
	Dmitry Vyukov <dvyukov@google.com>, Theodore Ts'o <tytso@mit.edu>,
	yebin <yebin@huaweicloud.com>,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] block: Add config option to not allow writing to mounted devices
Date: Wed, 14 Jun 2023 00:10:26 -0700	[thread overview]
Message-ID: <ZIln4s7//kjlApI0@infradead.org> (raw)
In-Reply-To: <20230613113448.5txw46hvmdjvuoif@quack3>

On Tue, Jun 13, 2023 at 01:34:48PM +0200, Jan Kara wrote:
> > It's not just syzbot here; at least once in my life I accidentally did
> > `dd if=/path/to/foo.iso of=/dev/sda` when `/dev/sda` was my booted disk
> > and not the target USB device.  I know I'm not alone =)
> 
> Yeah, so I'm not sure we are going to protect against this particular case.
> I mean it is not *that* uncommon to alter partition table of /dev/sda while
> /dev/sda1 is mounted. And for the kernel it is difficult to distinguish
> this and your mishap.

I think it is actually very easy to distinguish, because the partition
table is not mapped to any partition and certainly not an exclusively
opened one.

> 1) If user can write some image and make kernel mount it.
> 2) If user can modify device content while mounted (but not buffer cache
> of the device).
> 3) If user can modify buffer cache of the device while mounted.
> 
> 3) is the most problematic and effectively equivalent to full machine
> control (executing arbitrary code in kernel mode) these days.

If a corrupted image can trigger arbitrary code execution that also
means the file system code does not do proper input validation.

This isn't meant as an argument against protecting the write access
(which I think is good and important), but we shoudn't make this worse
than it is.


  parent reply	other threads:[~2023-06-14  7:10 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 [this message]
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
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=ZIln4s7//kjlApI0@infradead.org \
    --to=hch@infradead.org \
    --cc=axboe@kernel.dk \
    --cc=bvanassche@acm.org \
    --cc=dvyukov@google.com \
    --cc=jack@suse.cz \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=tytso@mit.edu \
    --cc=walters@verbum.org \
    --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).