3 ms·

Sudo provides access control for root access, it's definitely not useless. Sudo allows for logging and locking of root actions. Those settings can be configured

Sudo provides access control for root access, it's definitely not useless. Sudo allows for logging and locking of root actions. Those settings can be configured irresponsibly and lead to compromise for sure, but the main purpose is creating a sense of order to who can access what protected resources. Without sudo (or doas, or something like that), you're just running su whenever you want without real access control. For a timeshared system with a lot of users, handing out root in this fashion is especially irresponsible.

closeparen 6y ago
If a malicious sudoer has access to basically any system utility that takes a filename, and the filenames are not explicitly enumerated in sudoers, you're owned. The only way your claim here really holds is if you're limited to very specific pre-defined scripts with limited degrees of freedom in their arguments. That is a fine thing to do. But when your operational processes are that structured, you're more likely to be doing code-reviewed changes to a configuration management repo, poking the API of a cluster scheduler, running playbooks in Ansible Tower or Jenkins, or something else that doesn't involve personal shell access.
- easterncalculus 6y ago
  Your point certainly stands, a lot of privilege escalation occurs because of sudo configurations like that. The idea that fine-grained access control necessarily implies that you're using something like Ansible or Jenkins for everything isn't necessarily true though, there are plenty of reasons why you wouldn't want to use those packages specifically, or if it's just an old-school timeshared computer. Sudo regulates those other utilities, and not the other way around. Even if using something like Ansible sudo is great because of the logging that it provides. Sudo works as a standard way to regulate admin (or other group) access, whether automated or not. That's why Ansible uses sudo as the become_method by default.

closeparen 6y ago

If a malicious sudoer has access to basically any system utility that takes a filename, and the filenames are not explicitly enumerated in sudoers, you're owned. The only way your claim here really holds is if you're limited to very specific pre-defined scripts with limited degrees of freedom in their arguments. That is a fine thing to do. But when your operational processes are that structured, you're more likely to be doing code-reviewed changes to a configuration management repo, poking the API of a cluster scheduler, running playbooks in Ansible Tower or Jenkins, or something else that doesn't involve personal shell access.

easterncalculus 6y ago
Your point certainly stands, a lot of privilege escalation occurs because of sudo configurations like that. The idea that fine-grained access control necessarily implies that you're using something like Ansible or Jenkins for everything isn't necessarily true though, there are plenty of reasons why you wouldn't want to use those packages specifically, or if it's just an old-school timeshared computer. Sudo regulates those other utilities, and not the other way around. Even if using something like Ansible sudo is great because of the logging that it provides. Sudo works as a standard way to regulate admin (or other group) access, whether automated or not. That's why Ansible uses sudo as the become_method by default.