[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aEm-fINS0Wyn2GXH@remnant.pseudorandom.co.uk>
Date: Wed, 11 Jun 2025 18:35:56 +0100
From: Simon McVittie <smcv@...ian.org>
To: oss-security@...ts.openwall.com
Cc: Marc Deslauriers <marc.deslauriers@...onical.com>
Subject: Re: Linux kernel: HFS+ filesystem implementation
issues, exposure in distros
On Wed, 11 Jun 2025 at 12:14:36 -0400, Marc Deslauriers wrote:
>On 2025-06-06 09:40, Attila Szasz wrote:
>>I didn't make this explicit in the video, but this works when
>>running as a non-sudoer user, and also on Ubuntu Server. I think
>>Canonical Product Security might have better estimates on this, but
>>I'm guessing many of the corporate, gov, academic, HPC cluster, etc
>>use cases are impacted practically in such a setting.
>
>This isn't supposed to work for non-privileged users, and not on
>servers. We allow mounting usb drives for admin users sitting at the
>console by shipping a package called "policykit-desktop-privileges"
>which contains the following polkit rule:
>
>[Mounting, checking, etc. of internal drives]
>Identity=unix-group:admin;unix-group:sudo
>Action=org.freedesktop.udisks2.filesystem-mount-system;org.freedesktop.udisks2.e
>ncrypted-unlock-system;org.freedesktop.udisks2.filesystem-fstab;
>ResultActive=yes
I don't think that stanza is relevant here, because it's about "system"
or "internal" disks. udisks2 has a concept of whether a disk is "system"
or not: see the source code for full details, but a short version is
that internal HDDs/SSDs are "system" and USB thumb drives are not,
possibly modulo some corner cases like running your OS from a USB thumb
drive.
The policy for non-"system" disks is different, and more permissive,
with the expectation that users of a laptop/desktop-class system will
expect to be able to plug in a USB thumb drive and access its contents.
By default this policy applies to anyone with an active local session,
not just admins.
The files in actions/ define actions, and for convenience, also define
default policies for those actions that are intended to be "usually what
you want" for three commonly-distinguished classes of session: active local
sessions, inactive local sessions, and everything else. The files in
rules.d/ (or localauthority.d/ for old versions of polkit) override
those default policies according to the requirements of the OS
integrator or the sysadmin, and can make use of finer-grained inputs.
In this case, /usr/share/polkit-1/actions/org.freedesktop.UDisks2.policy
defines org.freedesktop.udisks2.filesystem-mount for removable media
that are physically located in the same "seat" grouping as the user's
active local session, with a default policy of <allow_active>yes</>.
Compare with org.freedesktop.udisks2.filesystem-mount-system and
org.freedesktop.udisks2.filesystem-mount-other-seat in the same file,
which are considered to be dangerous and by default require
authentication with a sysadmin's credentials (auth_admin or
auth_admin_keep). This might vary a bit on older distros but should be
fairly similar on anything from the last decade.
However, on a server-class or HPC system, I would not normally expect an
untrusted user to be able to sit at the console and log in to a text or
GUI session; instead the server would usually be somewhere that the user
cannot physically access, and they would be logging in remotely via ssh
or VNC/RFB or something. So their session would not be considered to be
"active and local", and it is *that* that would usually protect servers
from those users being allowed to plug in removable media. The polkit
default policy for remote users would come from <allow_any>, instead of
<allow_active> or <allow_inactive>, and the default for <allow_any> is
usually "auth_admin", "auth_admin_keep" or "no" for all but the most benign
actions.
A second line of defence is that filesystem-mount normally only applies
to removable devices associated with the same seat as the user's
session, but remote logins aren't associated with a seat at all, so it's
impossible to find a device that belongs to the same seat; so even if a
drive is not considered to be "system", and even if the <allow_any>
policy is quite permissive, the user would be attempting the
filesystem-mount-other-seat action, which is more restricted than
plain filesystem-mount.
udisks2 might also consider some filesystems (the higher-risk ones) to
be inherently "system" even if they are located on removable media; or
if it doesn't already do that, it might be reasonable to teach it that
only an allowlist of known-robust filesystems like FAT are candidates
for the org.freedesktop.udisks2.filesystem-mount action, with a
different action that has a more restrictive default policy used for the
higher-risk filesystems.
I believe there is already code to ensure that filesystems mounted by
unprivileged users are mounted with options like nosuid and nodev (if
they support multiple users at all), whereas root-equivalent users
mounting system drives can probably bypass that restriction.
smcv
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
