[SOLVED] How do I allow an unprivileged user to update the system?

demolitions · 2024-08-21 11:00:10

I'm sorry if this is the wrong board, I've tried to search around both in the forums and on google, and found no applicable solution.

Among my colleagues there are some Arch users and some Manjaro users, we work in IT infrastructure and software development, and most of them want to keep using Arch or Manjaro.
My company is getting ISO certified and one of the required steps to introduce is to allow only IT security staff to install or remove software from any of the workers' computers, but they can be allowed to update their system.

My first solution has been to remove sudo and polkit rights for the user, and allow only "pacman -Syu" to them, and it works, they can update the system but not install packages.
How can I extend this permission to allow them to update AUR packages also? I cannot allow them "pacman -U" since this means allowing them to also install packages.
I have tried most of the AUR helpers I could stomach, but none offers a solution to this problem, and I don't want to have them run those with sudo.

One of the solutions I am inclined to is, since we mostly use all the same AUR packages, with some minor exceptions, I could host a private repo in which me or others from the security staff can push binary packages built from AUR, and have all the others use that repo with pacman, would this solve the problem?
Also, if that solution is viable, can anyone give me a few pointers on how to host a private repo with AUR-built packages?

Solution:
Hosting a private repository in which the security staff builds and pushes built and signed AUR packages, adding that repository to every worker's pacman.conf and allowing only "pacman -Syu" in sudo solved the issue.
Maybe in the near future will also host a main repos mirror, to "freeze" updates monthly.

Last edited by demolitions (2024-09-03 09:40:14)

gromit · 2024-08-21 11:05:56

Just so you know, you can also install a package foo like so "pacman -Syu foo", so maybe you need to double check your rule

Regarding a private repo most people use aur utils: https://github.com/aurutils/aurutils
You can then expose this repo via $protocol (i.e. https or internal http etc.) and add the database to each users pacman.conf:

[custom]
SigLevel = Optional TrustAll
Server = http://repo.vpn.heusel.eu

You might also want to do proper signing etc. (which I skip for my local repo)
I think paru also supports something like this but I never used it ..

Whoracle · 2024-08-21 11:06:54

To host a repo yourself, you just need a webserver that hosts the contents of a folder, and apart from that follow https://wiki.archlinux.org/title/Pacman … repository

Last edited by Whoracle (2024-08-21 11:07:18)

demolitions · 2024-08-21 13:13:20

gromit wrote:

Just so you know, you can also install a package foo like so "pacman -Syu foo", so maybe you need to double check your rule

If I'm not mistaken (and I could well be), allowing "/usr/bin/pacman -Syu" in sudo prevents the use of any arguments other than "-Syu", isn't that how sudo works?

In case I'm wrong (I'll verify shortly), how should I allow my users to update?
I could write a binary executable that spawns "pacman -Syu", disregarding any other arguments and links standard I/O streams, so that my users can launch "sudo myupdater" with any arguments the want, they won't be passed to pacman.

Do you see any problems with that approach?

khaalid · 2024-08-30 17:40:34

just to make sure i understood you well if you want to allow a user to upgrade the system is only sudo or polkit i don't know there is other way well actually pacman is strage somehow because you can do same thing with pacman -Syu, -Sy and -S all this options can install packages. But hey you can combine pacman and yay if you are using as aur helper others are same

seth · 2024-08-30 19:16:18

allowing "/usr/bin/pacman -Syu" in sudo prevents the use of any arguments other than "-Syu", isn't that how sudo works?

Ideally, yes (and it also precludes heresies like "-Suy" )

How can I extend this permission to allow them to update AUR packages also? I cannot allow them "pacman -U" since this means allowing them to also install packages.
I have tried most of the AUR helpers I could stomach, but none offers a solution to this problem, and I don't want to have them run those with sudo.

This is the money quote in your OP and differs from the subject (in nuance)
You'll have to host a private repo - any pacman wrapping AUR helper that's not utter garbage will allow you to inspect (and edit) the PGKBUILD on invocation and at this point you've completely surrendered what *actually* gets installed.

You could probably build a script that checks pacman -Qm, drops privileges to clone the AUR, "immediately" immutes the PKGBUILD, then drops privileges to build the package and installs it, but
1. there're twice opportunity for exploting a race condition to inject PKGBUILD and package
2. an uncontrolled AUR build w/o intervention on the PKGBUILD is incredibly bad style

icar · 2024-08-30 20:21:49

Have you considered distributing system immutable images without pacman? There are several tools, for example, https://github.com/Vanilla-OS/ABRoot.

ua4000 · 2024-08-31 12:50:48

demolitions wrote:

My company is getting ISO certified

Changing "some" parts like sudo won't do it.
You are starting at the wrong step.

a) secure the hardware: disallow users BIOS access, disallow boot order change. Else they can boot a live medium and revert anything.
b) secure the bootloader: No acces to the boot commandline. Else they replace the init system, and are root.
c) implement a user role concept in your company with audit / history, and strict user <> root roles.
d) + many more things

So get professional help here, security is not done by tweaking some technical sudo things.

seth · 2024-08-31 21:47:27

There's one more thing I had missed before:

allow only IT security staff to install or remove software from any of the workers' computers, but they can be allowed to update their system

Security aside: You need to assess whether that's a good idea at all.

The current matrix is "untrusted users" and "untrusted actions"
"Updating" an AUR package is an untrusted action, it can only be performed by trusted users.
Updating repo packages is a trusted action, so it can be performed by untrusted users.
BUT!
It is not a reliable action.
You're not supposed to run unattented updates and running them by an untrusted usergroup is at least unattended-adjacent.

It is also not common or sane practice to allow users to change their (production) system (including through updates) willy-nilly. That's effectively what got us the crowdstrike disaster.
Normally™ the IT runs an integration test on a test system (or multiple) and only if that pans out fine then updates the production systems in response.

Arch is a rolling release distro that doesn't really do integration tests (to what exact configuration? When your test is done, the test system is outdated)
Let's say the user updates the system, all runs fine (ie. no incidents during the udpate that any IT needs to deal with) but the updated kernel doesn't boot on their specific hardware.
The user now cannot do their job until the IT moves in to downgrade the system for them.

demolitions · 2024-09-02 08:34:35

ua4000 wrote:

demolitions wrote:
My company is getting ISO certified
Changing "some" parts like sudo won't do it.
You are starting at the wrong step.
a) secure the hardware: disallow users BIOS access, disallow boot order change. Else they can boot a live medium and revert anything.
b) secure the bootloader: No acces to the boot commandline. Else they replace the init system, and are root.
c) implement a user role concept in your company with audit / history, and strict user <> root roles.
d) + many more things
So get professional help here, security is not done by tweaking some technical sudo things.

Who said we are "starting" from this?
Please don't assume that what I'm asking is the first step we are doing, as I said, ONE of the required steps is this.
Neither you should assume which certification we are proceeding towards, since there are multiple different certification tracks, with different security requirements.

I am not STARTING from this, I'm trying to allow my users to keep using Linux since the "professional help" around us just wants to migrate everyone to windows.

A) Not required by certification, but already done, except on some hardware that won't ask for BIOS password on boot menu (almost all DELL enterprise laptops do that), we are slowly phasing out that hardware.
B) Not required by certification, and next step (after package installation/updates) is figuring out a secure bootloader or one that can be secured.
C) Already done, both.
D) One thing at a time, I'm now looking at package installation and want to keep my users able to install updates, since the certification allows that.

Thanks for the thinking points, but please can we stick to the question? The rest is being handled or in the roadmap, and is not what I asked.

demolitions · 2024-09-02 09:18:03

seth wrote:

There's one more thing I had missed before:
allow only IT security staff to install or remove software from any of the workers' computers, but they can be allowed to update their system
Security aside: You need to assess whether that's a good idea at all.
The current matrix is "untrusted users" and "untrusted actions"
"Updating" an AUR package is an untrusted action, it can only be performed by trusted users.
Updating repo packages is a trusted action, so it can be performed by untrusted users.
BUT!
It is not a reliable action.
You're not supposed to run unattented updates and running them by an untrusted usergroup is at least unattended-adjacent.
It is also not common or sane practice to allow users to change their (production) system (including through updates) willy-nilly. That's effectively what got us the crowdstrike disaster.
Normally™ the IT runs an integration test on a test system (or multiple) and only if that pans out fine then updates the production systems in response.
Arch is a rolling release distro that doesn't really do integration tests (to what exact configuration? When your test is done, the test system is outdated)

We have mostly 2 different application setups, customizations aside, and 2 almost identical hardware setups, either of which is used by at least one member of the security staff, so the idea has been for a few years that we do the testing, and when we are certain that no issues arise we give the green light for all the users to update, with any solution to apply before or after the updates. This usually takes only a few hours and no major problems have been reported from our developers in the 5 or 6 years we have done this.

seth wrote:

Let's say the user updates the system, all runs fine (ie. no incidents during the udpate that any IT needs to deal with) but the updated kernel doesn't boot on their specific hardware.
The user now cannot do their job until the IT moves in to downgrade the system for them.

Let's instead say I have my security staff log on remotely on the users' system, and update it (since having everyone here once a month to update is not a viable solution), all runs fine (no incidents during the update that is needed to be dealt with) but the updated kernel doesn't boot on their specific hardware.
What difference does it make having the user update their system or having a security worker do it?

We currently mitigate this problem by having a dual kernel configuration in all the systems (both LTS and current), and having users switch to the LTS kernel if the current is not booting, and trying (not always possible) to concentrate the updates on the less knowledgeable people on days in which they are in office.
And of course, having mostly the same hardware, all our laptops have an AMD CPU, either a Ryzen 5 or a Ryzen 7, all with AMD integrated GPU, and all but a few use KDE/Plasma as their DE, the main difference between the setups is the applications installed.

If there is a problem that needs to be addressed by one of our IT guys, either we give a spare (updated) pc to the user, or we fix their one if it can be done fast enough, this requires the user to be in the office or to come in if they aren't, this won't change with who does the updates.

Since we usually complete our tests in a couple of hours, and most of our users all update in another 3 to 4 hours, we never had anyone updating with a different set of packages than the ones we tested, do you think that the possibility warrants a private mirror for the official repos?

I have already set up a private repo for built AUR packages, and a bit of automation so that our security staff can check the PKGBUILDs before building and pushing the packages, adding a mirror for the official repos wouldn't be that big of a change.

seth · 2024-09-02 11:32:13

What difference does it make having the user update their system or having a security worker do it?

when we are certain that no issues arise we give the green light for all the users to update

Soft vs. hard barrier.
As mentioned, this is more a maintainance than a security concern. So if the users generally behave and don't run rogue updates and this established process works for you, there's nothing wrong with it.
The only difference that might be introduced is that because of the security precautions, the users are now precluded from fixing the situation themselves.

Trilby · 2024-09-02 12:56:57

I may have only skimmed some longer posts here - but I've not seen mention of what appears to be a critical point here. It is not even logically well-defined in arch what is meant by being able to "update" but not install new software or remove software as these are really the same thing. For a specific case, lets assume package A is to be updated and the updated package A includes a new dependency. Now the "update" process requires the addition of new software that was not on the system before.

Any sudo or other security policy that allowed updates would allow such additions. I doubt this would satisfy the certification requirements.

Allowing AUR packages then compounds this by making this quirk much easier to deliberately exploit to effectively install any package at any time, even when only "updating" an existing package.

Last edited by Trilby (2024-09-02 12:58:21)

demolitions · 2024-09-03 09:36:32

I am marking this thread as solved, since the suggestion about hosting a private repo has provided an adequate solution to the problem.

Thanks everyone for the useful thinking points.

demolitions · 2024-09-04 13:29:46

Trilby wrote:

I may have only skimmed some longer posts here - but I've not seen mention of what appears to be a critical point here. It is not even logically well-defined in arch what is meant by being able to "update" but not install new software or remove software as these are really the same thing. For a specific case, lets assume package A is to be updated and the updated package A includes a new dependency. Now the "update" process requires the addition of new software that was not on the system before.
Any sudo or other security policy that allowed updates would allow such additions. I doubt this would satisfy the certification requirements.
Allowing AUR packages then compounds this by making this quirk much easier to deliberately exploit to effectively install any package at any time, even when only "updating" an existing package.

You are right, this is a point that has not been mentioned, and is actually a point that merits discussion with the legal team about the leeway we have in the certification requirements wording.
AFAIK the requirements state that the end user cannot install software either singularly or in bundle on their own, bot when the software comes as part of an update there SHOULD be no issue.

The AUR point is currently moot, since we do not allow direct AUR installation, but the AUR packages requested or updated will be validated and built from the security staff, so any additional packages will have been validated, I think this will fall under the same constraints as updates from the official repos.

I'm now thinking the unthinkable: since the hardware we use is mostly the same, I could mirror the official repos, so that I can "freeze" monthly updates, and schedule unattended updates with a cron job when the worker's pc is idle.
Please stop me

Thinking seriously, I may as well mirror the official repos, at least to unload them from our download bandwidth.

Last edited by demolitions (2024-09-04 13:31:11)

Trilby · 2024-09-04 13:59:15

demolitions wrote:

I'm now thinking the unthinkable: since the hardware we use is mostly the same, I could mirror the official repos, so that I can "freeze" monthly updates

Yes, you absolutely should. That would clear all this up quite nicely. But you probably don't need to mirror the full repos - rather just create your own repos that include all the packages that may be needed on the various systems. There will be some (probably quite a lot of the largest) packages in the repos that your team would have absolutely no use for.

As long as there is a means by which users could request other software be added it could work quite well. At that point it doesn't matter if the software they want is in the main arch repos or the AUR - it will be served to your user's as a built .pkg.tar.xz in a local repo.

Whether or not the updates are done via a cron job or the end user is less of an issue, I think. As long as their pacman.conf is set to use the local work repo(s) and they can't execute arbitrary pacman commands as root but just an update command, then you should be in good shape.

However, at that point, they're hardly even running arch linux itself, but rather your own home-rolled arch-like distro. This is fine, and this forum / community can help you maintain that arch-like distro, but it would be less appropriate for the users to come to this community for help: your users should go to you for help with this custom distro.

That said, all this is predicated on user cooperation. As physical access is root access, you can't really prevent them from installing whatever they want if they are motivated and competent. And if they lack either motivation or competence ... why are they there? If they lack both ... they must be the CEO

Last edited by Trilby (2024-09-04 14:00:49)

demolitions · 2024-09-04 14:37:52

Trilby wrote:

That said, all this is predicated on user cooperation. As physical access is root access, you can't really prevent them from installing whatever they want if they are motivated and competent. And if they lack either motivation or competence ... why are they there? If they lack both ... they must be the CEO

No truest words have ever been spoken

Indeed they already come to the IT staff for any problems that arise with configuration or package management, since we are the most knowledgeable (just in our company, of course) with linux, especially arch, I expect that this will just increase a bit the number of requests.

My hope is that they will now come with the INITIAL problem, instead of the 4 or 5 problems they created in order to solve the initial one, but as you said, this is all based on user cooperation, no amount of obstacles will keep a rogue employee to obtain root access on the laptop on which they have physical access, that is (and should be, IMHO) handled at the policy level, we're only trying to abide at the technical level to the certification requirements, we are actually asking for ways to let someone maintain their administrative access, but I don't think that it will be legally possible.

seth · 2024-09-04 14:53:36

https://wiki.archlinux.org/title/Dm-cry … ecure_Boot
Have. Backups!

Or you print out and hang up https://xkcd.com/838/ in every office

Arch Linux

#1 2024-08-21 11:00:10

[SOLVED] How do I allow an unprivileged user to update the system?

#2 2024-08-21 11:05:56

Re: [SOLVED] How do I allow an unprivileged user to update the system?

#3 2024-08-21 11:06:54

Re: [SOLVED] How do I allow an unprivileged user to update the system?

#4 2024-08-21 13:13:20

Re: [SOLVED] How do I allow an unprivileged user to update the system?

#5 2024-08-30 17:40:34

Re: [SOLVED] How do I allow an unprivileged user to update the system?

#6 2024-08-30 19:16:18

Re: [SOLVED] How do I allow an unprivileged user to update the system?

#7 2024-08-30 20:21:49

Re: [SOLVED] How do I allow an unprivileged user to update the system?

#8 2024-08-31 12:50:48

Re: [SOLVED] How do I allow an unprivileged user to update the system?

#9 2024-08-31 21:47:27

Re: [SOLVED] How do I allow an unprivileged user to update the system?

#10 2024-09-02 08:34:35

Re: [SOLVED] How do I allow an unprivileged user to update the system?

#11 2024-09-02 09:18:03

Re: [SOLVED] How do I allow an unprivileged user to update the system?

#12 2024-09-02 11:32:13

Re: [SOLVED] How do I allow an unprivileged user to update the system?

#13 2024-09-02 12:56:57

Re: [SOLVED] How do I allow an unprivileged user to update the system?

#14 2024-09-03 09:36:32

Re: [SOLVED] How do I allow an unprivileged user to update the system?

#15 2024-09-04 13:29:46

Re: [SOLVED] How do I allow an unprivileged user to update the system?

#16 2024-09-04 13:59:15

Re: [SOLVED] How do I allow an unprivileged user to update the system?

#17 2024-09-04 14:37:52

Re: [SOLVED] How do I allow an unprivileged user to update the system?

#18 2024-09-04 14:53:36

Re: [SOLVED] How do I allow an unprivileged user to update the system?

Board footer