4 ms·

> > But that is one of the headline features of sudo! For example it is the first item on its feature list here https://www.sudo.ws/about/intro/ https://www.sud

> > But that is one of the headline features of sudo! For example it is the first item on its feature list here https://www.sudo.ws/about/intro/ https://www.sudo.ws/about/intro/ > The ability to restrict the commands a user may run on a per-host basis. Is it? sudo is literally "substitute user [and] do" and it does exactly that: runs a certain program in the context of certain user. The only permissions sudo is concerned with is which user on what host is to be allowed to switch to which user, i.e. invocation permissions. Sudo simply does not care what permissions user+program combo may have. Without additional hardening, in unix-like systems local user account is the capability boundary and `sudo` is a tool to escape those boundaries. Sudo is just doing what it was designed to do here

zokier 3y ago
> The only permissions sudo is concerned with is which user on what host is to be allowed to switch to which user And, critically, what commands that user is allowed to execute. That is pretty crucial aspect of sudos use-case. The intent is to have ability to restrict what code the user is allowed to run as the target user, and not allow arbitrary code execution.
- friendzis 3y ago
  > The intent is to have ability to restrict what code the user is allowed to run as the target user, and not allow arbitrary code execution. No, that's not the intent. The intent is at best to limit binaries that are being run, but actual implementation is to limit invocation string. > That is pretty crucial aspect of sudos use-case. Agreed. Unless you 100% vet and control all sudo`able binaries in your system (probably 99.9% sysadmins don't), it is pretty crucial to understand that effectively sudo grants arbitrary code execution under x user permissions. That's by design. Executed code runs "natively", not in any form of sandbox, without any restrictions on permissions besides local user account. Some applications are explicitly designed to allow arbitrary code execution, some applications may have bugs allowing arbitrary code execution. Sudo is insecure by design. The main use of sudo is to protect against willingly cooperating users.

zokier 3y ago

> The only permissions sudo is concerned with is which user on what host is to be allowed to switch to which user And, critically, what commands that user is allowed to execute. That is pretty crucial aspect of sudos use-case. The intent is to have ability to restrict what code the user is allowed to run as the target user, and not allow arbitrary code execution.

friendzis 3y ago
> The intent is to have ability to restrict what code the user is allowed to run as the target user, and not allow arbitrary code execution. No, that's not the intent. The intent is at best to limit binaries that are being run, but actual implementation is to limit invocation string. > That is pretty crucial aspect of sudos use-case. Agreed. Unless you 100% vet and control all sudo`able binaries in your system (probably 99.9% sysadmins don't), it is pretty crucial to understand that effectively sudo grants arbitrary code execution under x user permissions. That's by design. Executed code runs "natively", not in any form of sandbox, without any restrictions on permissions besides local user account. Some applications are explicitly designed to allow arbitrary code execution, some applications may have bugs allowing arbitrary code execution. Sudo is insecure by design. The main use of sudo is to protect against willingly cooperating users.