Fedora 29's User PATH Will Prioritize Local User Binaries

[phoronix]

Phoronix: Fedora 29's User PATH Will Prioritize Local User Binaries

There have been several controversial Fedora 29 changes this cycle like hiding GRUB by default and catering i686 packages to x86_64 while another one was approved today at the Fedora Engineering and Steering Committee...

http://www.phoronix.com/scan.php?page=news_item&px=Fedora-29-User-PATH

[anarki2]

"But upstream believes there is no security concerns since users can already modify PATH on their own"

That's exactly why this change doesn't make sense.

[waxhead]

"But upstream believes there is no security concerns since users can already modify PATH on their own"

That's exactly why this change doesn't make sense.

And what about this change does not make sense? Can you give one example please?

To override a binary you have to place it in your ~/.local/bin and modify the path
with this change the difference is simply
To override a binary you have to place it in your ~/.local/bin
If you are able to modify ~/.local/bin it is very likely that you can also modify the PATH variable anyway.

Personally I think this change is cleaner and more "as it should be".

[zxy_thf]

And what about this change does not make sense? Can you give one example please?

To override a binary you have to place it in your ~/.local/bin and modify the path
with this change the difference is simply
To override a binary you have to place it in your ~/.local/bin
If you are able to modify ~/.local/bin it is very likely that you can also modify the PATH variable anyway.

Personally I think this change is cleaner and more "as it should be".

There is a security issue there. For example some malware can hijack common executables (say, ls) by putting a infected binary at $HOME/.local/bin, and each time you run "ls" you're actually running the malware.

Update: the real problem is, well, nobody checks those paths everyday -- including me. I just found a short script relying under my $HOME/bin, and I have searched it for a while...

[Tomin]

"But upstream believes there is no security concerns since users can already modify PATH on their own"

That's exactly why this change doesn't make sense.

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

[waxhead]

There is a security issue there. For example some malware can hijack common executables (say, ls) by putting a infected binary at $HOME/.local/bin, and each time you run "ls" you're actually running the malware.

I think we all understand that point of view, but as was pointed out in the original text you commented on , and as I pointed out, and as Tomin even made extra crystal clear: As long as the users can change their PATH variable , how on earth does having what it points to by default affect the security?!

To rephrase what you are saying a bit....
"Because the users CAN change the PATH variable, having it point to ~./local/bin instead of for example /usr/bin/ does not make sense."

This does not make sense to me.... does it to you ... really?

What does however make sense if I try to view it from your point of view, is that some users can be "stuck" with obsolete binaries that may be compromised as they are not updated as part of the system, but then again since they CAN change their PATH variable everybody can easily end up in that situation anyway. Changing the default solves more problems than it creates the way I see it.

[Guest]

waxhead - your argument foesndo make any sense. In the case of home users, who are also the admins of their own system, they can and do install updates. Plus, most distros enable automatic updates, especially security updates.

In the case of an office environment, where IT controls your system software, they'll keep your system up to date, installing security updates if needed. TherrfThe, your argument doesn't support your viewpoint in any way.

[waxhead]

waxhead - your argument foesndo make any sense. In the case of home users, who are also the admins of their own system, they can and do install updates. Plus, most distros enable automatic updates, especially security updates.

In the case of an office environment, where IT controls your system software, they'll keep your system up to date, installing security updates if needed. TherrfThe, your argument doesn't support your viewpoint in any way.

I am not sure I can make out what you are trying to explain. In case of home users or office environment there is no difference, someone else is updating the system for you. Either it be the distro maintainers or the IT guys at work and in both cases the correct way to handle your "security problem" would be to first of all have a sane PATH variable, and instead prevent read access to ~./local/bin

If there even is a "problem" then the PATH variable is not it, if anything the directory access is!

[oiaohm]

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

PATH ~/.local/bin and ~/bin to be moved to the top of the PATH list instead of the end.

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.

[cueball]

[snip]
What does however make sense if I try to view it from your point of view, is that some users can be "stuck" with obsolete binaries that may be compromised as they are not updated as part of the system, but then again since they CAN change their PATH variable everybody can easily end up in that situation anyway. Changing the default solves more problems than it creates the way I see it.

I get where this is going, but it does feel like an edge case type scenario; you suggest that someone is using an old updated system, but one who is able to recognise old obsolete binaries, and then install local tools... but it will be beyond them to update their path.

Building cases for/against detracts from the actual argument of usability v security IMHO.

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............?

It might be more interesting to find nice ways to tackle the underlying issue, eg;
-- maybe a setting to disallow overriding of system binaries?
no overloading "passwd", but you can use "passwd_myguy"

-- maybe allow recognition of "new" binaries that override system binaries?
eg once off query "did you know 'rm' is executing from ~/bin/rm? is that ok? [y/n/alwaysok/never]


just my 2c.