Sorry, don’t know where to post exactly but this is related to upcoming release so let it be here. OpenSuSE modifies $PATH environment variable adding ~/bin (if it exists) to the beginning even before /bin, /usr/local/bin and /usr/bin so any program running as regular user may put a binary or script called su or sudo or anything else to ~/bin hence “replacing” the actual system binary. It may show fake password request and then run real program supplying this password to it (to hide itself from user) and also run anything it wants as root (if user for example ran su or sudo without arguments). Any vulnerable application on user’s system may lead to getting full control over it’s machine via this vulnerability.
The problem is in /etc/profile. Take a look at this file and find the following lines:
#
# Make path more comfortable
#
if test -z "$PROFILEREAD" ; then
PATH=/usr/local/bin:/usr/bin:/bin
if test "$HOME" != "/" ; then
for dir in $HOME/bin/$CPU $HOME/bin ; do
test -d $dir && PATH=$dir:$PATH
done
fi
The line
test -d $dir && PATH=$dir:$PATH
should be corrected to
test -d $dir && PATH=$PATH:$dir
I think it would be good for security to fix it in upcoming 11.3. Well, the problem isn’t solved completely because any user’s program can correct ~/.profile or ~/.inputrc or any other file that shell executes while starting up. You may chown root:root them and check access rights — should be 755 or maybe even 644 (don’t know whether it prevent those files from executing). Also, you may chown root:root ~/bin and chmod it to 755 to prevent creating files there from user.
openFATE is probably the place for this sort of suggestion.
But if a rogue program can write in ~/bin, then it can also easily insert another PATH assignment in ~/.bashrc for the same effect. If you put ~/bin at the end of the PATH it would be less useful because then you couldn’t override the standard programs.
For GUI users, a rogue program could alter a launcher on the Desktop.
So you’re not safe if you run a rogue program whatever the PATH setting.
Again it’s a tradeoff between risk and utility. This trojan horse tactic is pretty well known.
Well, I also mentioned that you can chown (to root) your shell configs to prevent chmod’ing them and chmod (as root) to prevent writing to them. Shell configs changes not so often, that wouldn’t be a problem to sudoedit them.
BTW maybe it’s better not to overwrite standart programs but alias them using your shell configs. This would be nice centralized solution, only one file that you control. The drawback is that other programs will still call the original program but I can’t imagine a situation where you should completely replace a program for every other one.
Maybe the less painful solution will be creating the default ~/bin that’s chown’ed to root or nobody and has write access only for them. If you can create new user, you are root. Therefore you can either leave this directory as it is to prevent user from such attack or chown it to this user to allow him place anything he wants there. It’s easy to implement by modifying /usr/sbin/useradd.local
I don’t insist because there are no large known attacks of this type but it’s good to be prepared.
Well if you want to make a file immutable, it’s easier to use chattr +i, as this does not change the ownership. Although one has to be root to run chattr +i.
But that’s not the end of the danger. A rogue program could alter your browser bookmarks so that you go to bad.site when you think you are going to paypal.com. You couldn’t make the bookmarks file r/o because it would be rewritten when you add or delete a bookmark.
This sort of trojan horse attack is much further down the danger list than drive-by attacks using web browsers, flashplayer or acroread. So effort should go into preventing the high-risk issues, instead of this possibility.
BTW, if you intend to go down this path of locking things down, then you should look at a security framework like SELinux or Apparmor, which allows you to specify what agents are allowed to do what to which objects. The things you mention can be done as policies in SELinux. But when you deploy it in earnest you will understand why it’s normally only done on high exposure machines like servers, because it is a pain in the a** to specify everything legal and reject the rest.
In principle a SELinux machine can be made very secure. I remember that when it was announced, the developer said at the talk, we can give you the root password, and you can have a go at trying to disrupt the machine, but you will find that nothing dangerous has been allowed to root, even though you can login, and see that your uid is 0.
>
> Hi!
>
> Sorry, don’t know where to post exactly but this is related to
> upcoming release so let it be here. OpenSuSE modifies $PATH
> environment variable adding ~/bin (if it exists) to the beginning
It has been this way for many years, so it is intentional.
You can argue the point in the security mail list, for example (I
don’t see a security forum). But I suggest you first read the books they
wrote, in case they talk about this.
–
Cheers / Saludos,
Carlos E. R.
(from 11.2 x86_64 “Emerald” GM (Elessar))