Making Fedora usable for nonwheel users

[boredsquirrel]

I think this goal is quite important.

There are many deployments, especially for autoupdating (atomic) systems, where an admin may want to set things up once, and then barely have to touch it again.

Imagine

• school “Chromebooks”
• child/parent laptops ;D
• company workstations
  …

Having this working is not a huge issue but requires some small adaptions. dnfand rpm-ostree need to work without sudo rights. There need to be dedicated groups for privileged actions, to avoid needing to be in the wheel group.

There are many security benefits when not using “the default”, a user whose password can also be used to access, and break, the entire system.

Using dedicated groups with associated polkit actions, for flatpak,adb, libvirt, … will be a part of this.

Who is interested in joining this goal, test things out, create implementations to make Fedora usable day to day, without needing to be in the wheel group?

[mattdm (Matthew Miller)]

Hmmm. Can you elaborate more on the use case here?

@boredsquirrel

There are many security benefits when not using “the default”, a user whose password can also be used to access, and break, the entire system.

Using dedicated groups with associated polkit actions, for flatpak,adb, libvirt, partitioning, … will be a part of this.

If the goal is to make accidental breakage more difficult, this might help. But it also adds a lot of complication — and, I’m not sure it really offers much of a security benefit (at least not with some other major changes). If you have the ability to install arbitrary packages via DNF, you can run arbitrary code as root.

[boredsquirrel]

Use case: having unprivileged users use a built system.

Maintenance is automated in the background. The users cannot install but upgrade packages.

And the complications come from using dedicated groups for certain privileged actions, instead of “the wheel workaround”.

Like these said groups, if wanted.

Flatpak

This could have multiple ways.

Either allow users to modify their apps, by using --user repos. This does not need any privileges.

Or keep the standard with systemwide flatpaks and having users in the flatpak group. I think this is the default.

Or install some system flatpak apps and dont put users in the flatpak group, meaning they cannot install random stuff. In this scenario it needs to be sure that automatic flatpak updates still work, but nothing else.

[mattdm (Matthew Miller)]

@boredsquirrel

Use case: having unprivileged users use a built system.

I’m not trying to be snarky… I think this really needs a more solid definition of “users” and “use”. Is the user a random person at a kiosk? A family member? A student using a school-provided laptop? At work, a software developer? A designer? An office worker? What applications do they use and need?

Maybe use the “user story” format? (“As an embedded hardware developer, I need to access serial ports, so that I can deploy code to and debug microcontrollers connecting via USB.”, etc.)

@boredsquirrel

Maintenance is automated in the background. The users cannot install but upgrade packages.

This should currently be the case with GNOME Software.

Libvirt is already configurable with polkit, although to be completely honest I don’t remember how to do it nicely with the “new” javascript-based policy definitions.

[boredsquirrel]

I edited the post. The focus is on unprivileged users doing unprivileged stuff, accessing their user account, managing files, using apps etc.

With the scope of fixing issues that arise here. It may be that this is already the case, but it wasnt.

Additional to this base use, more privileges should all be possible to add without needing the wheel crutch.

I use that libvirt polkit rule but for some reason it doesnt work anymore, will need to debug.

This means

• testing (especially on rpm-ostree where it currently does not work but I have a change proposal for that)
• documentation of safe privilege extension

[boredsquirrel]

I linked many posts that are part of this goal, regarding many of the subgroups.

I think it is remarkable that there is a ton of tasks that involve quite complex setup of polkit rules, gsudo or unix groups.

[siosm (Timothée Ravier)]

See SIGs/ConfinedUsers - Fedora Project Wiki

Note that having access to the system libvirtd is equivalent to being root on the system. If you want to let unprivileged users runs VMs, you need to run a user instance of libvirtd.

You can already manage your Flatpaks without privileges if you install them under the user location instead of the system one.

Partitioning is inherently a privileged operation as you can compromise the system or destroy it with it.

[boredsquirrel]

@siosm

user instance of libvirtd

I never heard of that… does it have similar restrictions like GNOME Boxes Flatpak, where USB device access or TPM doesnt work?

I also dont understand why accessing libvirtd grants root on the host system.

Very interesting, I will look out for that! The default it systemwide libvirt, so I never knew this was even possible. Even the Distrobox hack requires a rootful podman container to run libvirt.

@siosm

Flatpaks without privileges

I think Fedora defaults to adding users to the Flatpak group?

There is no security benefit, on multi-user systems duplicating Flatpak wastes space. Data is separated. It could be interesting to put uninstall behind an admin password though.

Also user Flatpaks cant do certain privileged things, like GPU screen recorder. But that is an edge case and I dont fully understand the mechanism.

On restricted systems it makes little sense to allow users to change their apps. User flatpaks would allow anything. So modifying a polkit rule, adding a new user group “fusers” and only allowing updates could be useful here.

@siosm

Partitioning is inherently a privileged operation

Yeah, removed that, makes little sense.

[siosm (Timothée Ravier)]

@boredsquirrel

I never heard of that… does it have similar restrictions like GNOME Boxes Flatpak, where USB device access or TPM doesnt work?

Yes, this is what GNOME Boxes uses.

@boredsquirrel

I also dont understand why accessing libvirtd grants root on the host system.

See: 1284447 – libvirt group is unauthenticated root equivalent.

There are “options” to escalate from system libvirtd access to full root on a system.

@boredsquirrel

I think Fedora defaults to adding users to the Flatpak group?

No. Fedora defaults to system installed Flatpaks.

@boredsquirrel

There is no security benefit

Any (in)security claim must come with a threat model otherwise they are security theater.

@boredsquirrel

Also user Flatpaks cant do certain privileged things, like GPU screen recorder. But that is an edge case and I dont fully understand the mechanism.

The installation location does not determine what a Flatpak application can do. Neither system installed Flatpaks nor user installed ones can do privileged operations.

@boredsquirrel

On restricted systems

This is not the default use case for Fedora. This requires configuration.

[boredsquirrel]

Thanks.

@siosm

Fedora defaults to system installed Flatpaks

I meant it puts users into the flatpak group. Users in the groups wheel and flatpak can manage systemwide flatpaks.

@siosm

Any (in)security claim must come with a threat model

Fair point. Threats could be

• other people seeing what apps you have installed
• applications being able to escalate their privileges (which only systemwide ones can, with user consent)
• others updating or modifying your apps.

@siosm

Neither system installed Flatpaks nor user installed ones can do privileged operations

Well this is not true. Look at GPU screen recorder, it needs to be installed as a system flatpak to work.

@siosm

This is not the default use case for Fedora

Not yet, but a part of “making Fedora usable for nonwheel users”.

A: systemwide flatpaks

• users in the flatpak group can manage them
• users without cant
• an admin could manage them centrally

B: user flatpaks

• no group needed
• all users can do what they want (adding repos still requires a password)
• no central management possible

I think option A makes more sense as a default.

[siosm (Timothée Ravier)]

@boredsquirrel

I meant it puts users into the flatpak group. Users in the groups wheel and flatpak can manage systemwide flatpaks.

The default user created by Anaconda is not added to the flatpak group. I don’t think the flatpak group does what you said it does. Only wheel users can manage system Flatpaks via polkit. Have you verified this?

@boredsquirrel

Fair point. Threats could be

This is not a threat model. See: Threat Modeling | OWASP Foundation. You at least need to say:

• what you are protecting
• against what attacks
• and how

@boredsquirrel

other people seeing what apps you have installed

What’s the security issue behind that? This would be about privacy and even that is a strech.

@boredsquirrel

others updating or modifying your apps.

Only admins are able to modify system Flatpaks. User Flatpaks are only modifiable by the corresponding user they are installed under.

@boredsquirrel

applications being able to escalate their privileges (which only systemwide ones can, with user consent)

@boredsquirrel

Well this is not true. Look at GPU screen recorder, it needs to be installed as a system flatpak to work.

GPU screen recorder has access to outside of the sandbox (com.dec05eba.gpu_screen_recorder/com.dec05eba.gpu_screen_recorder.yml at master · flathub/com.dec05eba.gpu_screen_recorder · GitHub) and uses it to set capabilities on a binary on the host via pkexec: README.md - kms-server-proxy - A program to fix GPU Screen Recorder password prompt spam in flatpak. I don’t know why it claims that it needs to be installed system wide because nothing here should prevent it from doing it from a user Flatpak.

To give it a try:

$ flatpak --user install org.kde.kcalc
$ flatpak --user run --talk-name=org.freedesktop.Flatpak --command=bash org.kde.kcalc
# flatpak-spawn --watch-bus --host pkexec --user root id

Flatpak applications can only get as much privileges as the user they are running under if they have sandbox escape access. Any application running on the host (i.e. not in a Flatpak) can request more privileges via polkit, which may ask for a password depending on the policy. By default, for wheel users it will be the user’s password and for non wheel users, an admin’s password. See:

• https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html
• /usr/share/polkit-1/actions/org.freedesktop.policykit.policy.

@boredsquirrel

users in the flatpak group can manage them

As I said above, I don’t think this is the case.

@boredsquirrel

all users can do what they want (adding repos still requires a password)

Users should be able to add user level flatpak repos without privileges, passwords or needing to be part of a group.

$ flatpak --user remote-add flathub https://dl.flathub.org/repo/flathub.flatpakrepo

[boredsquirrel]

I don’t think the flatpak group does what you said it does.

true, my mistake.

>> cat /usr/share/polkit-1/rules.d/org.freedesktop.Flatpak.rules
polkit.addRule(function(action, subject) {
    if ((action.id == "org.freedesktop.Flatpak.app-install" ||
         action.id == "org.freedesktop.Flatpak.runtime-install"||
         action.id == "org.freedesktop.Flatpak.app-uninstall" ||
         action.id == "org.freedesktop.Flatpak.runtime-uninstall" ||
         action.id == "org.freedesktop.Flatpak.modify-repo") &&
        subject.active == true && subject.local == true && (
        subject.isInGroup("wheel") || subject.isInGroup("flatpak") )) {
            return polkit.Result.YES;
    }

    return polkit.Result.NOT_HANDLED;
});

polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.Flatpak.override-parental-controls") {
            return polkit.Result.AUTH_ADMIN;
    }

    return polkit.Result.NOT_HANDLED;
});

With this rule it would work, I think that would be a good addition?

@siosm

User Flatpaks are only modifiable by the corresponding user

@siosm

Users should be able to add user level flatpak repos without privileges

I think this is pretty problematic for restricted systems? Imagine a school laptop where you dont want the students to install Steam as user Flatpak for example, and run any game from there.

Can user Flatpaks be blocked somehow?

@siosm

To give it a try:

Thanks for the heads up, very hacky method.

[siosm (Timothée Ravier)]

@boredsquirrel

With this rule it would work, I think that would be a good addition?

Again, what do you want to fix/address with this?

@boredsquirrel

Can user Flatpaks be blocked somehow?

Fundamentally no, unless you completely mark the user home dir as non executable.

@boredsquirrel

I think this is pretty problematic for restricted systems?

See for example: Security objectives — CLIP OS 5.0.0_beta3 documentation

If you have the binaries available to run (system) Flatpaks, then there is nothing preventing you from pulling the content from Flathub and running it manually. If an user can run arbitrary code, then they can run anything they want.

[boredsquirrel]

@siosm

Again, what do you want to fix/address with this?

Allow the specific capability to manage systemwide flatpaks without needing to be in the wheel group.

@siosm

If an user can run arbitrary code, then they can run anything they want.

Thanks, I think this is off topic for this thread, but experimenting with nonexecutable home (with for example /var/usrlocal/bin being an alternative custom script location) is interesting for me.

[richiedaze]

I am willing to help bring this to fruitation. I believe in the separation of system and user.