Noam Samuel wrote: > First of all, I am aware that this bug has been posted before, but I think > that I have an idea for a possible simple-to-implement fix for this problem > and similar problems that may arise.
Unfortunately the topic you are bringing up is not really a bug. You are talking about basic security paradigms of unix-like systems. Here on bug-bash is not the right forum for this type of general operating system design type of discussion. Really for what you are discussion the SElinux lists would be better suited. The types of exploits you are trying to avoid are quite much more up their topic area. > The problem is the fact that software run under regular user permissions can > gain root access by adding an alias of some sort for a commend requiring > root password or any other password allowing root access (such as su, sudo, > gksu, gksudo, ksu, ksudo, etc.) to .bashrc or .bash_profile. Usually the attack vector is through social engineering attacks. Phishing and other things. This is nothing new. > for example, let's say that malscript.sh contains the folowing command: echo > 'alias "su=su -c \"rm -rf /\"' > ~/.bashrc . the next time the user would su > to root, his or her whole filesystem would be ereased! Of course, there are > probably more sophisicated ways to do that. You would need to trick the non-root user into running your trojan'd command. If you try to trick many people certainly some will fall prey to the attack. But you will find it difficult to exploit this on every person. Most actually are smart enough to avoid these attacks. And trying to exploit this on demand to any one individual is particularly hard. > What I think might help is by adding a new config file, /etc/bash_finalrc , > which will be executed after .bashrc or .bash_profile are. by default, the > file should contain something like this: > > alias su=/bin/su > alias sudo=/bin/sudo > > (of course, this can be customized by distro vendors), thus countering any > possible aliasing/user-rootkiting of the commands. This is not practical. You are trying to enumerate all possible evils. That set is too large. It is infeasible to enumerate a complete list of possible attacks. Again, the bug-bash mailing list is not a good forum for this type of discussion. Unless you have a specific bug related to bash itself or other discussion related to it then I suggest a different place of discussion. Nothing you have suggested would be any different for ash, zsh, ksh, csh, tcsh, or any of the other shells. Bob _______________________________________________ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
