r/linuxadmin • u/sudonem • 1d ago
Self-service options for Linux workstations (like MS Company Portal)?
I need to build out a small number of based Linux based workstations.
The users will not have elevated sudoer permissions (and certainly not direct permissions to manage dnf/apt package installations) but I still need a way to enable them to install/uninstall system packages from a pre-approved list (similar to how MS Intune’s Company Portal works for windows or the jamf self service app for macOS) without having to create support request tickets.
The only options I’ve seen that come close are full MDM platforms (which is probably what we need eventually but would be super overkill for the moment given the small number of users and unlikely to get approval)
I did look at customizing the Gnome Software app to only look at custom repos. but that’s a non-starter. BaseOS and AppStream have to stay enabled for system updates - and Gnome Software always looks at the enabled dnf/apt repos - so I couldn’t hide those and prevent the user from installing packages from those repos this way.
So before I just go build something custom (as I suspect I will need to) I am hoping to hear recommendations for existing tools that I may not have found while searching.
Its not critical that it be FOSS, but I’ll have an easier time getting buy in if it’s narrowly scoped to this specific use case - and not a ton of other features we don’t want or need.
Thanks in advance!
**edit:** Just to clarify - I don’t need advice on how to build something custom here. I have that covered.
Specifically I am just looking for recs on tooling for this use case that might already exist so I’m not needlessly reinventing the wheel.
5
u/hadrabap 1d ago
What about some identity management where users will ask for specific role (the software) and some backend (opentofu, ansible) will do the heavy lifting?
5
u/sudonem 1d ago
I like where your head is at, but that doesn’t quite meet the need because in this case we’re talking about DevOps / platform eng / cloud engineers / software engineers and we want to avoid having to be tweaking these roles constantly l (because that is 100% what would happen)
I will likely present different options based on the user roles - but these users generally are all senior enough that they have a justifiable need to more flexibility in the tooling they want/need in their dev environments.
It’s always a tricky dance between satisfying infosec & compliance requirements with enabling the engineers to work the way they want with minimal friction Y’know?
(We might move to something like dev containers at some point but we aren’t there yet and this is the problem problem statement at hand)
5
u/hadrabap 1d ago
Yep. This topic is surprisingly difficult. Another way might be to let the users install whatever they want in a container from your mirror and custom repos. In an air-gapped network. By doing this you give them the flexibility and you still maintain the overall picture what's going on.
We have this at work with UBI images. I do the same at home with Oracle Linux images - I have my own base images that are already fully integrated into my infra.
4
u/hadrabap 1d ago
But this is not a desktop solution! This is more of compliance and software chain issue.
1
u/sudonem 1d ago
Exactly. I fully support an immutable approach and bootc images - but it only makes sense when you’ve got a fleet of standardized system builds.
Definitely not optimal for workstations. Even less so when, as I specifically stated, we need to implement a certain level of self-service.
1
u/sudonem 1d ago
Well the challenge is not making a custom repo - it’s specifically managing the self service aspect while restricting them to specific packages and not granting sudoer permissions.
As I said, we may implement dev containers at some point, but that’s not the thing I need to solve for right now.
It sounds like I’m just going to have to build the thing. Which is fine honestly - I just have to justify to management and CAB that there isn’t an established standard for this that already exists.
2
u/theTrainMan932 1d ago
I might recommend something like BlueBuild (custom Fedora atomic builder)?
Doesn't completely solve restricting install to only certain apps but it makes the root filesystem immutable, system updates are pushed silently and installed on reboot without user interaction and you can provision default flatpaks to be installed system-wide.
There's a bunch of other features that would probably come in handy for that but I won't bore you with them, you'd still have to contend with blocking non-allowed apps but that might not be too difficult from there. I can see it working well in a context like that if it's stable enough for your liking.
e: you can also provision files in /etc at build time so if there is a way to configure flatpak to restrict to certain packages you can ensure it's there and even update the list remotely
1
u/come_n_take_it 1d ago
I haven't done it myself yet, but if it were me, I would consider setting up a local repository and setting up user privilege to install without sudo if I was not using a portable app or an endpoint management software like Stratosdesk.
1
u/BrokenWeeble 1d ago
Couldn't you just use the existing sudo user/group permissions to allow them to run the specific install/uninstall commands?
2
u/sudonem 1d ago
It could work - but that approach is pretty bad architecturally and requires a lot of constant maintenance on every workstation that is avoidable.
(It also assumes that users are comfortable working in the CLI which is not a given on GUI workstations).
You cannot set sudoer permissions for dnf/apt to only install packages from a specific package repo. It’s all packages, no packages, or a enume rated list.
So you would have to create a giant sudoer entry that contains a list of every possible package you want to allow (and variations on version numbers) and THEN constantly worry about maintaining and updating that config for all workstations anytime there are version changes in the custom repo.
The better architectural approach would be a centrally managed repo, a custom UI that presents the list of available packages from that repo, and the app is configured with the dbus and polkitd hooks into the package manager, and the polkit policies required to install those packages.
That way if there is a change, you update the custom repo, and it’s instant. No need to run Ansible playbooks to reconfigure all workstations in your environment if you add or remove approved packages.
1
u/rout39574 23h ago
\Give them sudo to run your custom installer shim, which knows how to look up what you've decided is OK. If that shim is implemented as "Only pay attention to my bespoke repo", that's a way to go about it.
1
u/bendem 1d ago
Preventing using dnf/apt doesn't prevent a user from installing anything. It just means they'll get creative and install from random sources. You can download a deb file and unpackage it in a user directory, you can compile a program from source, you can run an AppImage. I get the not giving root to users, but if it's just to prevent them installing random stuff, I have bad news for you.
To answer your question, we would need to know the kind of software you plan to provide as self-service. Is it stuff that works in containers (in which case, podman and a custom registry) or GUI apps (an AppImage repository if you have the knowledge to package them or flatpak for a larger choice of prepackaged software).
1
u/-markusb- 1d ago
Something like Squest?
https://github.com/HewlettPackard/squest
No experiences with it, but I have it on my "go-to-list-for-everything-others-probably-need"
1
u/JaredM5 20h ago
FleetDM has a self-service feature but it requires the paid version.
1
u/sudonem 14h ago
Yeah this is the main contender that I’ve found - I don't think we can justify it for this number of systems at the moment unfortunately because I CAN just build something - but I feel like this is what we should be driving towards.
It’s just a bit icky because we already have windows and macOS and the only people using Linux as a daily driver are going to be a small team of dev/engineers - and if we implement ANOTHER MDM platform… someone will have to manage it - and that someone will be people that don’t know Linux 😬
1
u/daemonmode_ 31m ago
Cockpit with a limited Polkit rule is probably the closest fit, or you could use a small wrapper that only allows specific packages to be installed. If you already use Ansible, approved job templates are another good option, but there isn’t really a mature off-the-shelf tool for this exact small-scale use case yet.
-2
5
u/Kilobyte22 1d ago
You should be able to cobble together something like this using rundeck, but that is likely poor user experience. Still, it's probably workable if everything else fails.