2

Lets say someone sits behind my laptop for a second and runs:

alias cd='Ha Ha, Got You :))'

or we run an unknown software/script/etc and it appends something to ~/.bashrc. like:

alias sort='rm -rf ~'

These are only examples of aliases; As you know, these things also can be done using functions:

 cd(){ echo "Removing everything you've got :D"; }

These situations are just imaginary examples, consider anything similar.

What about a small script?

sudo -n ls &>/dev/null
if [ "$?" -eq "0" ]
 then
  sudo "Some dangerous command"
 else
  cd $1
fi

Then alias cd="/home/user/.config/gtk/.cd.sh".

For the commands which have been ran in bash we can simply close and reopen our terminal, but what about the ones that been set in startup files, we can't check the files or list of aliases/functions every single time we run a terminal.

  • Any idea how to disallow malicious aliases and functions in an interactive non-login shell, besides just restarting the terminal? – wjandrea Apr 29 '17 at 15:56
  • Okay, here is two: first is going into another shell -> /bin/bash; the other is keeping a list of aliases in a script at a safe place (permission) which contains something like unalias -a; alias x='...'; alias y='...';. then running it with absolute path: /usr/local/bin/reload_aliases. – Ravexina Apr 29 '17 at 16:06
  • 3
    Never let untrusted people run commands in your name. Never let untrusted people run commands in your name. Never let untrusted people run commands in your name. Never let untrusted people run commands in your name. Most work places will insist that you lock your workstation whenever you leave your desk, and will hold you responsible for anything your workstation does. – AlexP Apr 29 '17 at 16:15
  • +1 @AlexP I want to add more " there is no patch available for human stupidity " no hard feelings , I read that somewhere :) – Alok Yadav Apr 30 '17 at 8:17
2

Introduction

Bash configuration files

Bash has a bunch of configuration (aka startup) files, it uses these files to setup a specific environment for each user.

Some of these files are located at /etc, one of them that I'm aware of is /etc/profile, it's a global configuration file and its settings will be applied into all sessions, another is /etc/bash.bashrc; We don't need to work around these files because of their location they already are protected and only root has the rights to edit them.

A very important directory which can help us a lot is: /etc/skel; Whenever you create a new user with home directory, the files within this directory will be used as a skeleton for your new user's home directory.

ls -a /etc/skel

.bash_logout  .bashrc  .profile

We can also use dpkg to find about these files:

$ dpkg -L bash | grep etc

/etc/skel/.bashrc
/etc/skel/.bash_logout
/etc/skel/.profile
/etc/bash.bashrc

we can see that these all are installed by bash.

How thing works in bash

An alias or function can be set in any of these files, so let see how these files will be used by bash.

From bash man page:

When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and exe‐cutes commands from the first one that exists and is readable.

so the order is: ~/.bash_profile > ~/.bash_login > ~/.profile

When a login shell exits, bash reads and executes commands from the file ~/.bash_logout, if it exists.

this one will be run every time we exit from a login shell, I can't see how this one can has any effects on our situation.

When an interactive shell that is not a login shell is started, bash reads and executes commands from /etc/bash.bashrc and ~/.bashrc, if these files exist.

so the most important fiel is ~/.bashrc, because almost 90% of bash shells which we run are in interactive and no-login mode. and if we have a look at this file we can see that it will look for another file named ~/.bash_aliases, if it was able to locate it, then it will source that file too.


Start taking care of these files

First of all we should move ~/.profile to ~/.bash_profile otherwise it does not matters if we protect ~/.profile file, someone can create a ~/.bash_profile and it will overrides our configs, so:

mv ~/.profile ~/.bash_profile

After that if you are not using a ~/.bash_aliases file then create it, again like above, someone can simply create this file and there is a chance that (s)he can alter or aliases within it.

touch ~/.bash_aliases

Finally use chattr to protect these files against edit and removal.

From chattr man page:

A file with the 'i' attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file and no data can be written to the file. Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.

sudo chattr +i ~/.bash_profile ~/.bashrc ~/.bash_aliases

We are done, Don't forget that whenever you want to edit these files you should first remove the -i attribute.

Reset everything without close/reopening terminal

Another workaround is, creating a file:

sudo touch /usr/local/bin/reload_aliases

Put your aliases there:

unalias -a
alias x='...'
alias b='...'

Make sure nobody can write into that file:

sudo chmod a=r,x /usr/local/bin/reload_aliases

Now every time you want to reload everything run:

/usr/local/bin/reload_aliases

Rollback

And if you ever changed your mind:

sudo chattr -i ~/.bash_profile ~/.bashrc ~/.bash_aliases
mv ~/.bash_profile ~/.profile
rm ~/.bash_aliases # if you don't use it
  • 1
    Won't defend against bash --rcfile=/home/evil/bashrc.bad (and let the luser issue commands to that shell). – waltinator Apr 30 '17 at 5:36
  • Can you explain it more? I can't get it how it's possible... cause definitely I'm not going to run such a command myself. – Ravexina Apr 30 '17 at 7:34
  • As O.P. said, he fears a Bad Guy executing a command defining evil aliases. You offered what was supposed to prevent this. I gave a proof-of-concept that it would not prevent this. Read man bash, and search for --rcfile. It says "Execute commands from file *instead* of the system wide initialization file /etc/bash.bashrc and the standard personal initialization file ~/.bashrc if the shell is interactive (see INVOCATION below)." (My asterisks) – waltinator Apr 30 '17 at 23:17
  • What if we close and reopen the terminal? that would do the work right? – Ravexina May 1 '17 at 8:14
0

If you do stupid things (walk away without locking screen, blindly run uninspected scripts from untrusted sources, etc), you will get bad results.

Trying to be clever enough to recover from bad practices has never worked before.

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.