Re: [RFC PATCH] xfsprogs: don't allow udisks to automount XFS filesystems with no prompt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Wed, Aug 23, 2023 at 03:36:30PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@xxxxxxxxxx>
> The unending stream of syzbot bug reports and overwrought filing of CVEs
> for corner case handling (i.e. things that distract from actual user
> complaints) in XFS has generated all sorts of of overheated rhetoric
> about how every bug is a Serious Security Issue(tm) because anyone can
> craft a malicious filesystem on a USB stick, insert the stick into a
> victim machine, and mount will trigger a bug in the kernel driver that
> leads to some compromise or DoS or something.
> I thought that nobody would be foolish enough to automount an XFS
> filesystem.  What a fool I was!  It turns out that udisks can be told
> that it's okay to automount things, and then it will.  Including mangled
> XFS filesystems!


> <delete angry rant about poor decisionmaking and armchair fs developers
> blasting us on X while not actually doing any of the work>

If only I had a dollar for every time I've deleted a similar rant...

> Turn off /this/ idiocy by adding a udev rule to tell udisks not to
> automount XFS filesystems.
> This will not stop a logged in user from unwittingly inserting a
> malicious storage device and pressing [mount] and getting breached.
> This is not a substitute for a thorough audit.  This does not solve the
> general problem of in-kernel fs drivers being a huge attack surface.
> I just want a vacation from the shitstorm of bad ideas and threat
> models that I never agreed to support.

Yup, this seems like a right thing to do given the lack of action
from the userspace side of the fence.

[ The argument that "prompting the user to ask if they trust the
device teaches them to ignore security prompts" is just stupid. We
have persistent identifiers in filesystems - keep a database of
known trusted identifiers and only prompt for "is this a trusted
device" when an unknown device is inserted. Other desktop OS's have
been doing this for years.... ]

> [Does this actually stop udisks?  I turned off all automounting at the
> DE level years ago because I'm not that stupid.]

Yeah, I turned off all the DE level automount stuff years ago, too.
It's the first thing I do when setting up a new machine for anyone,


> diff --git a/scrub/64-xfs.rules b/scrub/64-xfs.rules
> new file mode 100644
> index 00000000000..39f17850097
> --- /dev/null
> +++ b/scrub/64-xfs.rules
> @@ -0,0 +1,10 @@
> +# SPDX-License-Identifier: GPL-2.0-or-later
> +#
> +# Copyright (C) 2023 Oracle.  All rights reserved.
> +#
> +# Author: Darrick J. Wong <djwong@xxxxxxxxxx>
> +#
> +# Don't let udisks automount XFS filesystems without even asking a user.
> +# This doesn't eliminate filesystems as an attack surface; it only prevents
> +# evil maid attacks when all sessions are locked.
> +SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="xfs", ENV{UDISKS_AUTO}="0"

I think this is correct, but the lack of documentation on how
udev rules and overrides are supposed to work doesn't help
me one bit.

Ok, just tracked it through - only gvfs and clevis actually look at
udisks_block_get_hint_auto() from udisks, so at least the gnome and
lxde/lxqt desktop environments will no longer automount XFS
filesystems.  Who knows what magic is needed for other DEs, but this
is a good start.

Reviewed-by: Dave Chinner <dchinner@xxxxxxxxxx>

Dave Chinner

[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]

  Powered by Linux