The design is very human.

Yeah, you’re not wrong. What I meant was that polkit is conceptually equivalent to UAC (at least it is supposed to solve the same problem). However it’s not really a fair comparison, as “polkit on Linux” isn’t one concrete thing you can analyse, it’s more of a pile of Lego blocks, which you could assemble any which way. In theory, with Wayland you could build a secure polkit agent that would not allow the malware to interact with it.

In reality this is a moot point, as most privilege elevation is still done via sudo anyway.

UAC on Linux would require an almost fundamental architecture change, in a way contrary to most of how Linux is used now.

I would say the challenge is not in the architecture, but in the general fragmentation of the ecosystem. PolicyKit is basically an equivalent to UAC, but it’s not used universally by everything that needs elevated access.

I think the basic premise of this question, that Windows and Linux somehow have a different foundational security model that is or isn’t based on passwords, is not really true. Passwords play more or less the same role for any modern operating system – be it Linux, MacOS, Android, iOS, etc.

The only major difference is that instead of UAC, Linux has a variety of options (sudo, policykit, run0), which are implemented differently across different distributions. If your privileged user doesn’t have a password, in some cases this could lead to any program being able to elevate their privilege quietly, unlike UAC.

However, in many distributions you can set up a user with a password and enable passwordless local login, which would be almost equivalent to windows with no password.

Answering your question directly, the major threat to most consumer users is physical compromise or theft of device. Your statement that “physical access is game over” is not entirely accurate: disk encryption with a password is a very strong protection against unauthorized data access, but you need to use a password (doesn’t matter if it’s Linux or Windows).

Think about it this way: you’re downloading someone else’s code and running it on your system. The OS doesn’t care: it will give it access to everything your user has access to, but won’t give access to anything else.

So (under the caveat below) the software won’t be able to mess with your system because your user generally can’t mess with your system. However, you still need to trust the software, since it will be able to access e.g. your saved passwords, SSH keys, install a keylogger, etc. In comparison, the binary packages can be seen as safer, because they have more “eyes” on them, and there is more time between the code being published and you running that code on your system.

Caveat: if you run something like sudo make install, then, of course the risk is way higher, and the package definitely will be able to mess with your system up to and including destroying it.

Can you modify the script to release the lock after the process has started?

This is not entirely correct. Many distributions do enable encryption by default. Also, encrypting the /boot partition does not guarantee the integrity of the boot sequence, you need to enable and correctly configure Secure Boot for that.