On Sun, Jun 17, 2018 at 11:13:39PM +0100, Ian Malone wrote: > On 16 June 2018 at 13:50, Björn Persson <Bjorn@rombobjörn.se> wrote: > > Tomasz Kłoczko wrote: > >> On Fri, 15 Jun 2018 at 23:21, Björn Persson <Bjorn@rombobjörn.se> wrote: > >> [..] > >> > Don't forget that if your proof of concept can be modified to either > >> > overwrite or append to ~/.bashrc, then it's irrelevant to this debate. > >> > >> before ~/.bashrc is executed many other scripts executions > >> already is finished > > > > This is true and completely irrelevant. > > > >> Whatever you want to do over you account session or profile scripts it > >> is already _to late_. > >> Is that clear now? > > > > No it's not clear. I have no idea why you're rambling about the order > > in which Bash executes its startup files. The order doesn't matter, > > especially since the hypothetical attacker is supposedly unable to > > modify those files. > > > > You claimed to have a proof of concept that would demonstrate how some > > security hole can be exploited if and only if ~/.local/bin is listed > > before /usr/bin in PATH. I asked you to post your proof of concept. You > > didn't. I will therefore conclude that you don't actually have one. > > > > > Well, two things: > > 1. For example, a kiosk mode, where the home directory is wiped each > login would be made less secure. The profile for the GUI is set at > login, so writing .bash_profile has no effect on the GUI environment, > but an attacker able to place files where the user has write > permission could mask system binaries. Even if .bash_profile is not always read, .bashrc is read every time a shell is started (OK, not "every time", but often enough). So for example if I open a new tab in the terminal, or run some scripting plugin from an editor, etc, the effect is the same as overwriting .bash_profile. But more generally, if one uses a public kiosk that somebody else had logged into first, for *any* purpose requiring security, that is a grave mistake already. How would one even know that the gui they are accessing hasn't been substituted wholesale? > But a more major worry for me here, the reason I'm bothering to reply > to a thread about setting paths (though to be honest, someone who > doesn't understand how to do that may not have much business > installing unpackaged software, particularly when the examples are > developer tools): > > 2. The fact that a proof of concept cannot be provided is not a proof > that a change you make is secure. Take Spectre; that vulnerability has > been around for decades with no public proof of concept, or even > knowledge there was a vulnerability, yet it can be exploited from > Javascript in a browser. So this repeated insistence on providing a > proof of concept before a security concern is taken seriously is > fundamentally wrong, and I would be concerned to see it applied > elsewhere in Fedora. In this case we understand what the change in behaviour means, we just seem to disagree on how significant this is. We even know how any such exploit would look. The calls to provide a POC have the intent to take any such POC and tweak it to modify .bash_profile/.bashrc/.i18n instead, and thus turn the discussion around by showing that $PATH order is irrelevant to the attack. Zbyszek _______________________________________________ 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/6F643BHFN4DN5YD2XHVK5I5B7QC4I3KA/
