(Again, I'm not infosec expert, I'm just pulling from what I've randomly heard/read/learned through my time in QA and SW engineering.) On 06/14/2018 08:40 AM, Zbigniew Jędrzejewski-Szmek wrote: > [...] > hatever their privelege level might be. >>> >>> Executable directory? If you have power over user $HOME, you can change >>> user's $PATH. >> >> Is it so easy, though? >> >> I've seen many examples with .bashrc, but .bashrc only does it for bash >> (and only in interactive mode, IIRC). One has to do it for something >> like .xsessionrc -- frankly I'm not sure if there is such file that applies. >> >> OTOH, by adding .local/bin, the attacker does not have to care where (or >> how) to set the path, they really only need to drop new file. >> >> I guess my point is that it won't make attacks possible (they already >> are), but it might be making them easier. > > That's a very correct observation. In fact, this is the whole purpose of > this change: to make installing arbitrary scripts to be executed by the > user _easy_! So anyone who is arguing that this makes it so much easier > for the attacker, are also arguing that this makes it so much easier for > the user. > > We put the bar for _security_ measures much higher then mere inconvenience. > In fact we know that users have been installing software in ~/ > successfully before this change, and it doesn't allow them to do > anything they couldn't do before. Likewise, it doesn't allow attackers > to do anything new. So people who consider this irrelevant for security > assume that mere inconvenience _is not_ a hurdle for the attacker. What about attack success rate? OK, if it's a targeted, 1-on-1 attack, then attacker will either succeed or fail, so, sure, inconvenience is almost irrelevant because they will certainly invest the extra bit to look at pstree or something---to know where to hit. So yeah, that's off the table. 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 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. > Nevertheless, mere inconvenience _is_ a problem for many users. Well, so what? Missing an opportunity to make it easier for user to take down the shields? I'm fine with that. Note that "user" is not always just "someone doing something and knowing what". Take any chain of actions, and assess what they mean from security POV. It is my belief that these are impossible to distinguish: * (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. Thanks, aL. PS: And if (B) complains, we should rather try to educate them and not just do whatever they wish. This is OS, not McDonald's restaurant. -- Alois Mahdal <amahdal@xxxxxxxxxx> Platform QE Engineer at Red Hat, Inc. #brno, #daemons, #preupgrade _______________________________________________ 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/ONMQO7K7PH2DI7DYRKKD6MG3VGLX44BO/
