| ▲ | cyberax 4 days ago |
| If you're using `sudo` for something beyond trivial `reboot`, you're doing something VERY wrong. |
|
| ▲ | dbt00 4 days ago | parent | next [-] |
| If you're not in the user community of a tool, having an opinion on whether or not the replacement should work doesn't seem like it should matter to you at all. |
| |
| ▲ | cyberax 4 days ago | parent [-] | | The complexity of tools and the associated danger absolutely matters. |
|
|
| ▲ | baggy_trough 4 days ago | parent | prev | next [-] |
| What are you doing wrong? |
|
| ▲ | unrented7977 4 days ago | parent | prev [-] |
| Like.... apt-get? |
| |
| ▲ | zenoprax 4 days ago | parent | next [-] | | `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. | |
| ▲ | cyberax 4 days ago | parent | prev [-] | | 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. | | |
| ▲ | BHSPitMonkey 4 days ago | parent [-] | | My sudoers is set up to let me run update and upgrade (with no args) without a challenge, but not install. | | |
| ▲ | cyberax 3 days ago | parent [-] | | 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. |
|
|
|
