With NOPASSWD you would also invite someone pulling a `.deb` via `curl` as part of a supply chain attack in a some non-descript NPM package via a git hook or something.
I'm pretty sure I can b0rk the system by interrupting the upgrade in an inconsistent state. Or maybe inject some fun environment variables into the `apt-get` context. And I think you can launch the shell during conflict resolution for conffiles, giving you instant full access to the whole system?
A more robust design is to have a systemd one-shot unit that users can activate (via a trigger file or sudo).
So my point still stands and your example illustrates it perfectly. Either you use `sudo` for full root access or for something entirely trivial.
`sudo apt install my-custom-backdoor-script.deb`
With NOPASSWD you would also invite someone pulling a `.deb` via `curl` as part of a supply chain attack in a some non-descript NPM package via a git hook or something.
So you want users to be able to install any package? So that the attack surface is now literally all the Debian archive?
Yeah, no.
You either use `sudo` when you want full root access or for something completely trivial.
My sudoers is set up to let me run update and upgrade (with no args) without a challenge, but not install.
I'm pretty sure I can b0rk the system by interrupting the upgrade in an inconsistent state. Or maybe inject some fun environment variables into the `apt-get` context. And I think you can launch the shell during conflict resolution for conffiles, giving you instant full access to the whole system?
A more robust design is to have a systemd one-shot unit that users can activate (via a trigger file or sudo).
So my point still stands and your example illustrates it perfectly. Either you use `sudo` for full root access or for something entirely trivial.