F42 Change Proposal: Unprivileged Disk Management (system-wide)

Project Discussion Change Proposals
,
1

Finegrained disk management

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Wiki
Announced

:link: Summary

This proposal adds a new dedicated diskadmin group, allowing users to manage external drives without needing to be in the wheel group.

It will also enable wheel users to unlock and mount external drives without a password prompt.

:link: Owner

:link: Current status

  • Targeted release: Fedora Linux 42
  • Last updated: 2024-07-01
  • [Announced]
  • [ Discussion thread]
  • FESCo issue:
  • Tracker bug:
  • Release notes tracker:

:link: Detailed Description

Currently, to mount or (LUKS) unlock external drives, users need to be in the wheel group. Removing a user from the wheel group would prevent them from using external drives.

This enables an “admin” permission that is not tied to full root access on the host system.

It will be a change of the polkit rule org.freedesktop.udisks2.rules like following:

polkit.addRule(function(action, subject) {
	if ((action.id == "org.freedesktop.udisks2.encrypted-unlock-system" ||
		action.id == "org.freedesktop.udisks2.filesystem-mount-system") &&
		subject.active == true && subject.local == true && (
		subject.isInGroup("diskadmin") || subject.isInGroup("wheel"))) {
		return polkit.Result.YES;
	}
});

:link: Feedback

none yet

:link: Benefit to Fedora

This is a step towards the Confined Users goal. It enables a dedicated action, the mounting and unlocking of external drives, without needing all the other privileges that wheel users have.

:link: Scope

  • Proposal owners: changing a single rule, testing with nonwheel users in the diskadmin group on GNOME and KDE

  • Other developers: N/A

  • Release engineering: #Releng issue number

  • Policies and guidelines: Documentation needs to get an additional chapter on disk management with the diskadmin group.

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with the Fedora Strategy: Not sure, as it adds a nonstandard user group.

:link: Upgrade/compatibility impact

The polkit rule will be added, users will not need to enter a password if they are in these groups. No changes for users outside these groups.

:link: How To Test

On Atomic or traditional Fedora, place the above rule in /etc/polkit-1/rules.d/80-org.freedesktop.udisks2.rules.

This will be preferred over the default rule and you can test if it works.

:link: User Experience

By default, Anaconda puts users into the wheel group. These users will not need to enter a password when mounting external media or unlocking them.

It also allows to do these actions without being in the wheel group, by adding a user to the diskadmin group.

:link: Dependencies

None

:link: Contingency Plan

  • Contingency mechanism: this is a simple fix, not adding it will keep the previous wheel need
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No

:link: Documentation

Will be added afterwards.

Nonwheel users can be added to the diskadmin group:

sudo groupadd diskadmin sudo usermod -aG diskadmin USERNAME

:link: Release Notes

Users in the ‘wheel’ or ‘diskadmin’ group can mount and unlock external drives without a password.

Last edited by @boredsquirrel 2024-07-02T15:34:08Z

2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply giving that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

This is part of su-confined-users

4

Is that true though? I would think if the mounted filesystem contained an SUID binary, then that would grant the user full admin permission on the system. (And the problem isn’t limited to just SUID binaries. It may also be possible to create things like device nodes with lax filesystem permissions that would, e.g., allow unrestricted access to “sda”.)

5

Yes that is a fair point.

I know that mounting as noexec,nosuid is possible in fstab, possibly also using udisks2.

If this is possible in that scope, it would be very useful, but I think it is not.

Until then, it is a small improvement but at least one.

Currently users without wheel access cannot even do backups etc.

6

This proposal adds a new dedicated diskadmin group, allowing users to manage external drives without needing to be in the wheel group.
It will also enable wheel users to unlock and mount external drives without a password prompt.

Removable drives can be already mounted and unlocked without a password prompt, the actions this change mentions (org.freedesktop.udisks2.encrypted-unlock-system and org.freedesktop.udisks2.filesystem-mount-system) are used for “system” devices by udisks, removable devices use the org.freedesktop.udisks2.filesystem-mount action for mounting which already has allow_active set to yes so user in an active session doesn’t need to provide password or be in the wheel group.

Example of mounting a removable drive by a user not in the wheel group.

vojtech@fedora:~$ udisksctl info -b /dev/sdg1 | grep HintSystem
    HintSystem:                 false
vojtech@fedora:~$ udisksctl mount -b /dev/sdg1
Mounted /dev/sdg1 at /run/media/vojtech/0da4f4fa-47b2-4a4e-b402-1170c18ee1a3
vojtech@fedora:~$ groups
vojtech

For an internal/non-removable drive you get a password prompt

$ udisksctl mount -b /dev/vda1 --no-user-interaction
Error mounting /dev/vda1: GDBus.Error:org.freedesktop.UDisks2.Error.NotAuthorizedCanObtain: Not authorized to perform operation

but that’s how udisks always worked and this change explicitly mentions external drives which to me means removable.

1 Like
7

What @vtrefny wrote is my understanding as well. This is already the case. See /usr/share/polkit-1/actions/org.freedesktop.UDisks2.policy.

From memory, udisks mounts external media as nodev,nosuid by default.

Likely copy/paste mistake, it’s: org.freedesktop.udisks2.filesystem-mount

In general, for the Confined Users goal, I think that we should not be adding groups to “split” admin privileges. We should make all the operations that can be considered safe available to all unprivileged users (Changes/UnprivilegedUpdatesAtomicDesktops - Fedora Project Wiki) and mediate the ones that are not (such as mounting disks) with a privileged daemon, which is what udisks does here for removable drives.

See: Why polkit (or, how to mount a disk on modern Linux)

1 Like
8

Yes, nosuid and nodev are always used by default.

Yes I meant org.freedesktop.udisks2.filesystem-mount, I fixed this in my previous post.

1 Like
9

Thanks for the info.

This happens when mounting an SSD connected with a USB adapter, a common solution on Laptops.

This is really good to avoid privilege escalations.

I agree in parts. Uncritical processes should be allowed. The flags like nosuid can help to make them less critical.

But in this case, why can “external media” be mounted unprivileged, while externally connected SSDs can’t? Why can’t internal storage devices be mounted without privileges?

This seems a bit arbitrary.

Also the approach you mention has drawbacks, like needing user flatpaks, or being restricted to limited actions. Then if you need more privleges, you are back on wheel.

Example here: restricted users on a library PC can accese their USB sticks, but not a separate drive. That makes sense.

For people that use external storage devices for backups, this makes them dependend on wheel. Instead, they could just add themselves to the diskadmin group and not bother again.

10

You should probably investigate why your external SSD isn’t recognized as an external media.

1 Like
11

This may be because of my USB adapter, a fix would be adapter specific.

Does this also allow unlocking LUKS volumes?

Thanks for the heads up, I didnt notice the system in the actions. A better fix may be to have this solved.

But I had the exact same behavior on 3 different USB enclosures (full size HDD with power, SATA, NVME)

12

Regardless of whether the rest of this change proposal goes through, I agree users who are in the wheel group shouldn’t be prompted to enter their password for this. That’s more annoying than useful.

13

I wonder if it is something that could be fixed with a udev rule along the following lines (untested).

cat << END > /etc/udev/rules.d/60-mark-all-usb-drives-removable.rules
SUBSYSTEM=="usb", ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{removable}="1"
END
1 Like
14

Yes, good point!

Does this allow LUKS unlock?

15

I expect LUKS unlocking would be an orthogonal issue with respect to the device’s “removable” attribute.

16

uhm what does that mean? :sweat_smile:

17

Orthogonal is a software engineering term. It means two issues are unrelated – what concerns one should have no effect on the other. :slightly_smiling_face:

https://en.wiktionary.org/wiki/orthogonal

1 Like
18

I don’t think this is needed as described but made me think about it a bit more.

External drives not detected as removable are a bug and their detection should be fixed.
For correctly detected devices udisks2 already allows mount and unlock for the active session.

There are a few cases for system (internal) devices:

For live media the user is already in group wheel so there is no need to change something. To me it does not make sense to limit someone in a “disposable” use case.

For personal workstation installations the user already has access to the root password and probably checked the Administrator check box during installation. If it was not checked then the next paragraph applies.

In a setup where the machines are managed somehow the administrator makes the decision what to allow and what not. It may be as simple as adding a user to group disk and allowing org.freedesktop.udisks2.* or allowing only some system devices e.g. using x-udisks-auth in /etc/crypttab and /etc/fstab and allowing org.freedesktop.udisks2.filesystem-fstab and org.freedesktop.udisks2.encrypted-unlock-crypttab or can get really complex with custom udev and polkit rules.

Multi-boot setups could benefit from simpler access to other system devices.
Having your other OSes data easily accessible would be great.
For personal single user devices and live systems see above.
For shared devices there is the problem of being able to read other users private data on the other OSes. This is a decision the administrator has to make and may require quite some configuration. Here i see an option for improvement:

Allowing org.freedesktop.udisks2.filesystem-fstab and org.freedesktop.udisks2.encrypted-unlock-crypttab for the active session.
Adding x-udisks-auth to entries in /etc/crypttab and /etc/fstab is a simple task and could even be an install time check box. Shared system (internal) devices could then be used by all users of the system. I think of a shared family pc here. The problem is that it will
break existing setups which assume it is auth_admin_keep by default.

1 Like
19

Yes I think I agree that the detection bug should be fixed first.

No. The purpose here is to have an alternative to wheel, that allows users to not be admins and still do these actions.

The user may be in wheel, but normally you dont create a root account. Not sure how many people do that anyways, as it has a warning sign.

Do you know if this wildcard exists? Or if it does, would it be bad practice to use it?

I see that too. I would like to have some kind of a “building blocks” approach, where admins can just comment out / remove comments of some lines, and have the correct rule for their purpose.

Thats why it is F42, it needs an overhaul.

Yes, totally. This is a very common use case, and not solved with the usb-adapter-bug.

I am completely against this “security measurement”. Systems should be LUKS encrypted, otherwise there is no security.

Couldnt access to /etc/fstab allow executing random suid binaries and getting root access? As you can change the mount parameters of filesystems.

So this doesnt seem like a good approach to me.

The proposed udisks actions dont allow access to these files, its all done via the abstraction.

20

Todo

try and fix the issue of SSD USB adapters. Test what adapters are really broken (as I have this polkit rule since forever, allowing it passwordless for wheel).

This should not happen and thus not require this change.

Summary

I think even if the scenario I often encountered may have a different solution, we found out the other one, where users may want to access a shared drive with data.

Or in general, where a user may want to mount a drive interactively.

We base our “it works” experience always on wheel users. If users would be nonwheel by default some day, we would have tons of breakages.

These Change Proposals are here to allow easy modular privilege groups, without needing full escalation to wheel, or needing to understand polkit rules.

So harm reduction.

Question

Under these points of view, do you agree to it?