No. If you have a program that does a particular task you may be inclined to let users run it with sudo rights. This list shows how these rights can be used to - for example - read arbitrary files and show them to the unprivileged user.
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
I still don't get the issue, that's going to be true for any program you run, unless it explicitly check if it's running using sudo. That however assumes that the program should never run with elevated privileges, which may be equally wrong.
Unless a program is designed for a very specific task and should always run as a given user, I'd argue that having it check privileges is both surprising and wrong. It's not the job of the individual programs to check permissions.
Edit: I see what you're saying. Having mail being a program that a user is allowed to run with sudo, it basically the equivalent for giving them a sudo access to a shell, because mail can spawn a shell, but with the same privileges as the mail command had.
One of the listed binaries is `cat` and that `sudo cat file` is problematic because "it may be used to do privileged reads or disclose files outside a restricted file system."
Like, duh, that is what `cat` does. It's not the problem, it's the `sudo` is the problem. WAI?
The "mail" entry is a good example:
https://gtfobins.github.io/gtfobins/mail/
Did you know you can get a shell easily by letting users use "mail"?