On Sat, Jun 16, 2018 at 01:17:57PM -0400, Nico Kadel-Garcia wrote: > * Stolen passwords from penetrated hosts, used for SSH connections. > Copying a file to $HOME/.local/bin requires far less scripting and > awareness of existing contents than editing of .bashrc or .profile > that reveals timestamp changes of the edited file, and differs from > system defaults. Since the contents of $HOME/.local/bin are not > defined or definable, by its very nature, it's harder to audit. The system default would be that they are empty or contain the files that are put there by default. Not really harder to audit that a .bashrc file. Also if you can use SSH to access the system, you can just execute commands. If you can only copy files, why is copying content to ~/.i18n less bad? > * Fileshares of home directories. Many environments, especially > university environments, use NFSv3 with quite general access. Welcome > to write access to $HOME/ !!! And $HOME/.local/bin is notably less > apparent than $HOME/bin, due to the default lack of "ls" reporting of > contents of "." prefaced directories, and of the difficulty of leaving > security auditing to check .bashrc, .profile, etc. Still, why would an attacker then copy something to these directories instead of to ~/.i18n, or ~/.ssh/config or ~/.vimrc? Also if you want to do a proper audit of all executables in the PATH the first step would be to check the value of $PATH because this is something an attacker could also change to any other value that would need to be checked. And once you look at $PATH, ~/.local/bin is no longer hidden because it is in plain sight there, even easier to spot when it is at the beginning. > Does that give you enough examples of unnecessarily vulnerable vectors > opened by default by the casual assumption that "ohh, they could get > in another way, so I don't have to worry about the hole *I* am > suggesting opening up!!!" No, in your examples $HOME would be compromised anyhow already. 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/6ADYSLRDQ72VOPLMPMCN26ZSOJUBIWCV/
