The lesson here is just don't rely on sudo to give restricted permissions. I have been a Linux admin for 6 years and never had to do this, and pretty much every use case I've heard of has easily solved with a better method. If you need to give people access to certain files, make a group. If you need them to have certain capabilities of another user, let them switch to that user but not run privileged commands.
> > 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/
> 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
> 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.
> 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.
And sudo does its job, executing only that program as root. If the sysadmin turns out to not want users to be able to use all features of the program as root, that is their responsibility. Sudo is just a command executor, not a sandbox
It's essentially the same as setuid, which has a well-deserved reputation for being a very dangerous tool if used on a program without thorough scrutiny
