Fedora 29's User PATH Will Prioritize Local User Binaries

[slalomsk8er]

I don't know where the fedora guys get the idea that debain has

That is not in the debian default PATH list at all. That is a Ubuntu thing only.

/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Above is what a default Debian PATH looks like. No user directory paths by default.

It looks like it depends on the Debian version.

Not sure if I upgraded from 8 to 9 or started with a fresh install:

PATH=/home/username/.local/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/snap/bin

[bitman]

The idea is that if the attacker can add a binary they could also modify the PATH anyway.

But that is not necessarily true. If stars align correctly a malicious actor could exploit a vulnerable webapp to drop a file while being unable to modify PATH for used logged in through shell. This is not a big deal, but it could make exploitation a tiny bit easier. Like always, balancing security and convenience.

[oiaohm]

It looks like it depends on the Debian version.

Not sure if I upgraded from 8 to 9 or started with a fresh install:

PATH=/home/username/.local/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/snap/bin

I found why I could not see it
Its on my system in /etc/skel/.profile . ~/.profile is where all by aliases live. So /etc/skel/.profile is copied after new account is created to ~/.profile. First thing I do when I set up a new account is overwrite ~/.profile with my own so killing the change dead.

Its a hack in your shell configuration. If you using a shell that does not use .profile you don't have it either.

Just something extra has been added to my list to remove.

/etc/login.defs
Basically without .profile hacks you fall back to the login.defs. I was not thinking that this was just simple shell hacking.

[Delgarde]

But that is not necessarily true. If stars align correctly a malicious actor could exploit a vulnerable webapp to drop a file while being unable to modify PATH for used logged in through shell. This is not a big deal, but it could make exploitation a tiny bit easier. Like always, balancing security and convenience.

If you can drop a file into ~/bin, you can probably also drop a file over the top of ~/.bashrc. Seriously, if the attacker already has the ability to write files to your home directory, it really doesn't matter what the default $PATH is... it won't help.

[Tomin]

An attacker could also do this:

echo alias ls=~/Downloads/an_evil_script.sh >> ~/.bashrc

Maybe its better that we leave PATH permanently empty and always call our commands by path.

[Weasel]

Glad to see that there's at least some developers out there with a brain to make some decent decisions, instead of all the pseudo security bullshit. And yes anyone who "hates" this change for "security" is exactly the pseudo security preacher I'm talking about, with no actual basis. Yes, if you think I'm talking about you (who reads this post), then I am.

I mean, look at this gem:

An attacker could also do this:

echo alias ls=~/Downloads/an_evil_script.sh >> ~/.bashrc

Maybe its better that we leave PATH permanently empty and always call our commands by path.

...or, you know, just execute an_evil_script.sh DIRECTLY if he really had control and your user's privilege.

Really guys (not you, the others), drop this pseudo security bullshit mentality, ffs. Anyone who can "drop" files in .local/bin (which is under your user, so only you can acess) can already execute his fucking program, if he somehow managed to gain your user's privilege. Why would he round trip his exploit by dropping it there at all? Not to mention, he can modify your .profile to begin with, LOL.


Ah, I know you're wondering "but what if I use sudo and then I execute an_evil_script by mistake?" as a cop out. Sorry, sudo changes PATH and won't run your .local/bin, it will say program not found Pseudo security at its finest but I'm not surprised to see the same people worried about this change as usual.

[Tomin]

I mean, look at this gem:...or, you know, just execute an_evil_script.sh DIRECTLY if he really had control and your user's privilege.

Sure. I probably shouldn't have used shell to express myself here. If the attacker had no ability to run anything on the system but enough to add files and replace old ones like already suggested, they could replace .bashrc with their own version. That way they could add their script to the .bashrc and it could do anything they wish. (not limited to replacing ls).

My post was a reply to the issue of being able to replace ls. It had nothing to do with the fact that there are other more convenient ways of attacking.

[labyrinth153]

The move to base of x86_64 CPUs is great. Lucky they even have an i686 port.

[waxhead]

Isn't the point that people are making is that, whilst making it 'easier' for the end user ... you also make it 'easier' for shenanigans.
Just because its easy to break glass doesn't mean you should leave your window open. Or, in this case, maybe its half open............?

Well in this case it would be more of situation where the Window has already been open and you choose between half-open or fully-open. You can still get in, but in one case you have to give the window a little push before entering.

[nanonyme]

I guess you could use Flatpak around browsers to provide user-controlled filesystem isolation