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!
*nod*
> <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,
too.
.....
> 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.
--
Dave Chinner
david@xxxxxxxxxxxxx
