Would flatpaks work for your purposes? It would allow users to install applications, but not mess with anything important.

I did that with my kids laptop on OpenSUSE, added him to the flatpak group and installed flathub as a user instead of system using the --user flag. He can install applications to his hearts desire, but they won’t mess with the system

I’d suggest a different approach. Instead of trying to lock down the loaner, which probably is going to be difficult to do against someone with physical possession anyway, just make a drive image of the loaner before giving it to them. When you get it back, just restore the image.

Lots of rambling in this comment. Solution below the heading.

From a security perspective of limiting privileges it doesn’t quite work. If they can run apt install then they can install a malicious hand crafted package, that has an install script that runs with root privileges, or enables a systemd service or so on.

From a preventing users from doing stupid stuff, it mostly works. Of course, there are still ways it can break, like when Linus Tech Tips typed in yes, do as I say when apt had a bug and refused to continue because it suspected that something would break and then Linus did it anyways…

But it will mostly work.

I want users to be able to install apps, but only from the the gui software manager and apt install in the terminal.

Firstly, I want to mention that flatpak does not need root and can work without root. So if the goal is to have users be able to install apps from the app store, you could remove non flatpak apps from the GUI, and then they would be able freely install and remove apps from the GUI app store. They can also use the flatpak cli, but it’s more difficult to use.

Secondly, I agree with the other commenter. It’s probably way easier to make a backup, or use syncthing, and just give them root if that getting them apt packages the goal. If you do something like automatic btrfs snapshots (which Linux Mint has support for), it mostly gets you to the goal of “I don’t want a privileged user to break their system”, since it is easy to walk them through booting into an older snapshot over the phone.

If your goal is actual management of apt programs, then the specific problem you are encountering is that there are two methods of authorizing to root, and you have configured only one of them so far. There is sudo, which governs cli programs, but there is also polkit, which governs GUI programs. Polkit has a cli command that has a similar feature to sudo, pkexec, which you can use for testing configuration of polkit.

Since it looks like you got sudo working I won’t waste time on that. Here is a nice intro from Red Hat:

https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/desktop_migration_and_administration_guide/policykit

Hmm doesn’t have what I want. (I am figuring out as I go).

Okay it looks like the GUI stuff is powered by packagekit, which is an actual daemon: https://en.wikipedia.org/wiki/PackageKit (I thought it was just a library/interface), that runs as root. You can use the pkgcli to interact with it from the command line, and it still uses polkit.

Okay here is the relevant policy file: https://github.com/PackageKit/PackageKit/blob/main/policy/org.freedesktop.packagekit.policy.in

Solution Here

Polkit rules are written in javascript, so you would want a rule that’s something like:

polkit.addRule(function(action, subject) {
    if (subject.isInGroup("GROUPNAME") &&
        subject.local &&
        subject.active &&
        action.id.startsWith("org.freedesktop.packagekit.")) {
        return polkit.Result.YES;
    }
});

And put this in /etc/polkit-1/rules.d/10-enable-rootless-packagekit.rules

This does read from the local unix groups, not active directory groups, meaning you have to ensure it’s present there, and also have the exact name, which is not used in the sudoers file example above.

if you run getent group, then it should be exact name of the group in that list.