[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-devel-list
Subject:    Re: Restricting automounting of uncommon filesystems?
From:       "Richard W.M. Jones" <rjones () redhat ! com>
Date:       2023-07-24 15:51:38
Message-ID: 20230724155138.GF7781 () redhat ! com
[Download RAW message or body]

On Mon, Jul 24, 2023 at 11:45:26AM -0400, Solomon Peachy via devel wrote:
> On Mon, Jul 24, 2023 at 04:00:21PM +0100, Daniel P. Berrangé wrote:
> > If I acquire a new USB flash stick I've never plugged in before, I
> > don't want it auto-mounting before I can wipe & reformat it.
> 
> Honestly, what makes more sense to me is treat this whole thing purely 
> as a usability problem.  Upon insertion, prompt the user to "mount, 
> mount reat-only, check, ignore", because at least then we'd get an 
> really easy method of fscking a disk without having to do the whole 
> unmount dance.  It also provides a mechanism to supply user feedback (eg 
> showing fsck results, or the XFS case where you _have_ to mount the 
> filesystem to replay the journal before an fsck can be safely run)

You don't actually need to do any of this if you're using libguestfs,
because the worst that can happen is the filesystem will pwn the
kernel inside the KVM appliance (which is just a userspace process, so
you can kill it).

> If the filesystem is dirty, the dialog always is displayed (with an 
> appropriate message recommending fsck), but if it's clean, the user can 
> dismiss the dialog with prejudice and have it always accept that drive 
> in the future.

A bit in the superblock marks the filesystem as clean or dirty, and
that has nothing to do with whether it is malicious.

> We can also provide a hot-key (eg hold down shift when inserting the 
> drive) to tell the system to always show the prompt even for previously 
> whitelisted devices.
> 
> This IMO improves the general usability of the system, instead of making 
> things universally worse, while simultaneously providing the hooks 
> necessary to implement better security.
> 
> Again, let's be realistic about the threat models here -- the 
> overwhelmingly common situations are accidental corruption due to 
> improper shutdown/ejection, and malicious files on a well-formed 
> filesystem (eg ransomware or something that's banking on users having we 
> passwordless sudo in place, or curl https://url/setup.sh | sudo bash) 

I do agree here.

> So let's make things better for those before worry about mitigating APTs 
> that need lots of system-specific awareness in order for an attack to 
> succeed?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[prev in list] [next in list] [prev in thread] [next in thread]