Hi,

Is it possible to stop users from copying a login shell, say bash, to another name and then executing it via sudo to gain root priviliges?

Normal users have read access to login shells, so they can copy them without any limitations. How can I stop this?

Thanks

Sudo doesn't work that way (unless you've configured it wrongly).
When you specify a command in the sudoers file (via visudo), you specify the full path to it. If a user renames a shell to be the same as an existing command in their sudo command set, the path will still be wrong so it won't work.

If you use wildcards in the sudo config, you need to be careful that you don't allow the execution of user created binaries. Do this by only allowing wildcards within filesystems the users have only read access to. In general, keep wildcards to a minimum as they open a lot of hard to forsee options to your users.

Thanks for the reply, but I'm still uncertain.

The issue I want to stop is as follows:

A user makes a copy of /usr/bin/bash and renames it to /home/user/not_bash.

Since the copy has been done under the user's account, and not via sudo, there's no checking to see whether the command is allowed or not. Bash executable has read access for everyone, so making a copy of it is not restricted.

Now, what's to stop the user from executing the following:

sudo /home/user/not_bash (or any other name)

to elevate themselves to root?

I do not want to specify every individual command the user is allowed to run via sudo as I would need to list the majority of o/s commands as I want users to be able to perform most system commands, just not be able to elevate to the root account (or any other user's, for that matter).

have you read the sudo man pages?

Sudo Manual

sudo determines who is an authorized user by consulting the file /etc/sudoers

if you have user_A assigned the profile of shutdown and user_A copies the bash file over to user_B in a different location it will not work because user_B is logged in and authenticated already as user_b and the sudo file will check this when they try to login to the shutdown profile.

I understand how sudo works.

How does sudo stop my above example from occurring?
The user copies the bash executable to another name. This copy occurs with normal acess rights, because /usr/bin/bash has read access for everyone.
No sudo authentication has occurred.
The user either copies, or moves, bash executabe to another name, say /home/user/this_is_not_bash.
Still no sudo authentication.

Now, the same user runs "sudo /home/user/this_is_not_bash"
Sudo checks sudoers file, and there is no restriction on running /home/user/this_is_not_bash (or any other name the user decides on)

The user has now been elevated to root.

Bash executable has NOT been copied to another users profile, it is being used to elevate (or switch) to another users account.

How do I stop this from occurring?

Hang on, are you saying you have granted sudo rights to users that lets them run anything they want from their home directory? Forget bash, you've got far bigger security risks by doing that - see my earlier post on this thread.

Forgot about the home directory. Path could be /tmp, /var, /usr or anything else - it's not important.
/home/user/this_is_not_bash was only used as an example.

What I want to stop, pure and simple, is a user copying a shell executable (bash, ksh, sh, etc) to any other location and then executing it via sudo.

It's unrealistic to think all users are the same. Some require greater freedoms (like admins) and they can't be locked down as tightly as you suggest. They require access to more commands than need to be restricted. In these cases, wouldn't it be easier to allow all commands and only restrict the handful that they shouldn't be using?

Is it possible, without having to specifically list (even with wildcards) every allowed command in sudoers?

Is my previously defined example possible on your system, and if not why not?

Thanks

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?