Cybersecurity

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