Is there a way to prevent all commands from being defined as an alias?
For example a user shouldn't be able to define
rm or any other command (Ubuntu default commands) as an alias name.
There is no way you can prevent a user from defining whatever aliases they prefer. Consider:
You could disable aliases at compile time, then it would be up to you to keep bash up-to-date and make sure you aren't affected by the next Shellshock. Of course, the users could build their own bash.
The only way to prevent a user from creating aliases is to provide them with a shell that doesn't support aliasing. This is generally an X/Y problem, where X is really a threat model that should be solved with appropriate controls or architectures rather than trying to solve the problem post-facto after a user is given a shell on a shared system.
Below, I provide a technically-correct answer, as well as some guidance on what problems this will and won't solve. I also provide some additional guidance on alternative controls.
Using the Bash Restricted Shell
You can use Bash's restricted shell by assigning rbash as the user's login shell. For example:
You must then disable the alias built-in for the user, preferably without breaking everyone else's shell too. As an example, you could add the following to a file such as /etc/profile.d/rbash.sh:
Unless you've placed the user into a chroot jail or provided them with a modified PATH that doesn't include access to other shells, there's nothing stopping the user from simply typing
In addition, by design the restricted shell prevents many common activities such as changing directories:
but doesn't prevent other scripts or programs in the PATH from doing so. This means you have to carefully craft the user's environment, and specifically that you need to prevent them from being able to modify the PATH in their startup files, because even though rbash makes PATH read-only it does so after initialization.
Even if you use rbash, you need to do so as part of a broader set of controls. Some examples may include:
Once you have accurately defined your threat model, you can identify the most appropriate controls for your use case. Without a more meaningful understanding of why you want to prevent aliasing (e.g. what real-world problem does it solve?) you can't select the most appropriate controls.
This is quite a pointless endeavor, as muru's answer shows. But there are some options, but they are not perfect.
You could place function definition into the systemwide
Another idea I've played with is
Again, using systemwide
You could define (in