Why not? The way Windows does it should work in theory I think?
Maybe you can't realistically do it on Linux, because Linux doesn't care about desktop security and doesn't have the kind of privileged GUI that you need.
Windows is a bit different I suppose. Many pieces come together to make it kinda work there.
* Privileged gui to display and approve what will run as you mentioned. In Linux, non-privileged gui is used to request permission to do... something.
* Executable verification. Let's say someone with user level permissions swaps out the program you wanted to run for a malicious one. The replacement would not pass certificate checks which would be revealed in the privileged gui. Maybe you could supply an old version with known vulnerabilities though idk?
* Kinda commandline parameters verification. In Linux-land you can pass parameters to the program those could be intercepted with user-level permissions. In Windows this would be displayed in the privileged gui. However! The parameters are only visible if you click "show more" which I would guess <1% of people actually do.
As an example of the last point I tested making a shortcut to cmd.exe and used Run As Administrator. Then I changed the shortcut to C:\Windows\System32\cmd.exe /c calc and again did Run As Administrator. Opens calculator instead of command prompt with identical approval gui (except with show more).
The way Windows does it is users are prompted to elevate permissions, and can be tricked into clicking "Yes," just like users can be tricked into using sudo.
But the entire threat model we were discussing was that the user might be tricked:
Being a setuid binary means that sudo also suffers from attacks where an attacker runs `sudo ./malware` and then convinces the user to authenticate
That's why the OP said that's not an enforceable security boundary. If the user is capable of attaining superuser privs, you can trick them, regardless of how attaining those privs is implemented.
* Privileged gui to display and approve what will run as you mentioned. In Linux, non-privileged gui is used to request permission to do... something.
* Executable verification. Let's say someone with user level permissions swaps out the program you wanted to run for a malicious one. The replacement would not pass certificate checks which would be revealed in the privileged gui. Maybe you could supply an old version with known vulnerabilities though idk?
* Kinda commandline parameters verification. In Linux-land you can pass parameters to the program those could be intercepted with user-level permissions. In Windows this would be displayed in the privileged gui. However! The parameters are only visible if you click "show more" which I would guess <1% of people actually do.
As an example of the last point I tested making a shortcut to cmd.exe and used Run As Administrator. Then I changed the shortcut to C:\Windows\System32\cmd.exe /c calc and again did Run As Administrator. Opens calculator instead of command prompt with identical approval gui (except with show more).