Cybersecurity

even if they copy a shell to thier homedir. this is not going to elevate their privledges. unless they have either the root password, or explicitly allowed to become root with the sudoers file, and if that's the case it's a moot point. a shell, bash or otherwise doesn't elevate privledges.

Maybe I haven't defined by question correctly.

What I want to stop is a user elevating to root via the following:

sudo bash.

This is easy enough to do via a sudoers restriction on running the command.

Now, I have a group of admins that need to be able to run most system commands. However, I want to be able to log all commands they run as root, for auditing purposes. So I use sudo.log.

The user bypasses sudo logging if they execute su or a shell via sudo. As mentioned above, I can prevent this by explicitly denying the commands in sudoers file.

However, if the user (or admin) copies a shell (say /usr/bin/bash, but could be any shell) to another location/name (could be any location or name), what's to stop them now executing this renamed and relocated shell command via sudo, which in effect, gives them root access without sudo.log logging.

Please don't get hung up on homedir being the location - it could be any directory with write and execute permissions.

So, is it possible on your system for a user to copy(rename) a shell command to another location and then execute it via sudo?
If not, why not?

This is what I want to prevent.

Hi,
Yes any user can copy bash to /userpath/notbash
But when a non root user issues a sudo notbash,
the user will need to enter root's password to gain root priveleges.

If correct password is not entered, it will not be executed. So it remains secure.

Hope this answers your concern.

This is not correct. sudo only requires the user's own password.

If I understand correctly, you have configured sudo to allow these users to execute any command they want, and then separately prohibited the shell, in order to prevent them from evading the logging.

The problem is that you cannot enforce your policy if you have a "permit unless prohibited" policy. Only with "prohibit unless permitted" and by explicitly listing the commands the users are allowed to execute as admin can you meaningfully enforce your policy.

These are your options; I don't think you like the answer, but that's how it is. Either explicitly list all the permitted commands, or live with the fact that some user could come up with a workaround to evade the logging. If you trust them to run arbitrary commands, what's to prevent them from installing a remote backdoor if they wanted to? It's "turtles all the way down".

Thank you Era, I suspected the prohibit unless permitted policy was going to be my only option. I was hoping that someone had worked some magic so that I didn't need to go down that path since, in my environment, the number of permitted commands far outweighs the number of restricted commands. As they say, the easy way is seldom the right way.

If you have logs of the commands they have executed, isn't that pretty much a listing of the set of commands you want to permit?