Hi, On Thu, Jun 14, 2018 at 04:19:27PM +0200, Alois Mahdal wrote: > On 06/14/2018 08:40 AM, Zbigniew Jędrzejewski-Szmek wrote: > What about attack success rate? > But if the attacker is some browser exploit able to take a shot at many > users (not knowing what their OS, let alone default $PATH is), then I The browser knows the OS, see the User-Agent header, for example: User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36 Name Also the PATH would be in the browser environment, so easy to access, too. However, if this information is not available to the attacker, why would they know the value of $HOME/bin or $HOME/.local/bin? They would have to know the user's username for this. IMHO these are not convincing assumptions. > believe every next, more sophisticated step is less likely to be > included. For example, they might not really feel it worth to include a > working algorithm to look at whether user uses .bashrc, .xsessionrc, > .zsh, .profile or whatnot. Ie., leaving out ~/.local/bin would result > in **worse success rate** for them. Most users will use .bashrc and since it would be the file that is under discussion here, only users that use it would be affected by the change. Also attackers do not need a fancy algorithm, they can just manipulate several files instead of doing sophisticated checks. And again, as I already wrote, either ~/.bashrc is affected or not, you cannot properly argue that it is affected in the way that it is read to set he path but is not affected in the way that it will not be read anymore after an attack. > * (A) user doing something and knowing what & why, > * (B) user copy/pasting some info from (untrusted?) github README.md, > * (C) an (untrusted?) program run by user intentionally, > * (D) malware running via exploit. > > And if you make the change in $Subj, you can only make it for all of the > above or none. > > Inconvenience is not that much of a problem for (A), because it's not > likely that they would know what they're doing and not recognize why > it's not working (and blame Fedora). > > Making it more convenient for (B) and (C) is IMO not worth given that > we'd also make (D) more likely to succeed. If there is already malicious code running with access the user's home directory, the PATH setting is the least problem for the user because the assumed problem for the PATH setting was that it would allow attackers to get code executed. Kind regards Till _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/X5NXDI2THGPZ4O6IBMS3XM55H4JYRYBV/
