1

I am trying to alias commands such as shutdown, reboot, etc. I am aware that this is not a fool proof way to block access, however this is just to prevent accidental execution.

I have looked at superuser.com/questions/244342 and all the links given within it.

To alias something like sudo /sbin/shutdown I would first have to alias sudo individually and then /sbin/shutdown to echo 'Not allowed'.

However this doesn't seem to work as sudo obviously executes it at root. So, aliasing these in the .bashrc of the user is pointless. How do I go about solving my problem? I do not want to modify any system attributes such as the .bashrc of root user, etc.

yass
  • 2,574
Utkarsh.K
  • 11
  • 2

3 Answers3

1

As you have correctly observed, shell aliases are not suitable for your purpose.

The correct way to avoid accidental execution of these commands with sudo is to update your configuration of sudo (using visudo) and prevent access completely. You could designate a group whose members are allowed to execute these commands with sudo, and nobody else.

janos
  • 3,505
1

Ok so the 'correct' approach is to not give these users sudo, but it seems like this is one of those situations you can't avoid giving the users this access (Lets say you did stop them running shutdown, they might just rm -rf /* instead)

However, to stop them running specific commands via sudo, you can control it in the sudoers file:

Firstly we define an alias for shutting down a system in /etc/sudoers.conf

Cmnd_Alias SHUTDOWN = /usr/sbin/shutdown

And then we remove the ability for anyone in the wheel group, to run this command:

%wheel ALL = ALL, !SHUTDOWN

This means that all users can run all commands on all machines, other than those in the shutdown cmnd_Alias.

man sudoers will explain this in far more detail, and in fact contains almost this exact explanation. Also note, this would not stop someone deliberately trying to run the shutdown command, only those who accidentally ran it without realising (maybe because they are logged into the wrong machine).

djsmiley2kStaysInside
  • 6,943
  • 2
  • 36
  • 48
0

Even if you successfully prevent the user from running all commands that are directly responsible for a reboot, a user with sudo access (where the sudo access isn't whitelisted to a specific set of binaries that they lack permission to modify, and which can't possibly be manipulated into running reboot code) can still reboot the system via:

  1. Download the source code to a program like reboot or halt (e.g. in GNU binutils, IIRC), compile it using gcc, then run sudo ./reboot on their local copy.

  2. Write a program in Ruby, Python, C/C++, Java, etc. that calls the appropriate syscalls to initiate a reboot or shutdown.

  3. There are probably tricky things they can do with symlinks or hardlinks to get around a blacklist. These things are always difficult to handle from a security perspective, but I don't have any concrete examples off the top of my head.

If you're 100% sure that all the binaries you give the user the permission to run under sudo can't be manipulated into executing arbitrary code (which leads to items 1 or 2 above), then maybe it'd be OK. But a crafty user (or program running as that user) can still exploit security vulnerabilities in any of those programs to elevate and reboot/shutdown.

If you're completely confident that all users with sudo access will cooperate with you and not attempt to do things they're not allowed to do, then the blacklist should be fine to prevent "accidents". But then you should be prepared to accept the consequences if someone decides to deviate from policy for whatever reason.

If you have any sliver of doubt about the users, it's better to give each user a VM or a secure container.

allquixotic
  • 34,882