On Wed, Jun 13, 2018 at 05:28:03PM -0400, Stephen John Smoogen wrote: > The usual culprit in the past has been where an attacker gets access > via a chrooted or container environment where they only have access to > a limited set of directories. A long time ago this was done via ftp
I read this as there is an actual security vulnerability to begin with. > and some other remote filesystem which were common in universities and > thought safe by itself. Or the attack would be done by controlling one > host with root permissions and using NFS or some other global > filesystems to put a trojan in one system and then getting the admin > to execute it on a different system. This was why it was a security I do not follow why the attacker would only have access to ~/bin or ~/.local/bin and can only add files there but not read or modify other files. > finding for a long time in various checklists that user controlled bin > directories needed to be at the end of the path. It was also linked to IMHO "it is on a checklist" without proper justification is probably just security theater. There are enough possibilities to manipulate files in $HOME and it usually contains the important user data so that it should be protected properly so that one can properly assume that only the user or administrators can access the data therein. AFAIK selinux does this already and admins need to explicitly label directories to allow protected services to access them. And this whitelisting approach is the right thing to do from a security perspective instead of trying to blacklist useful features for a IMHO negligible or imaginary security gain. All in all, there are already a lot of possibilities to escalate from write access to $HOME to code-execution regardless of ~/bin or ~/.local/bin that I strongly believe that $HOME needs to be secured and considered to be safe for their user. Otherwise I would like to see CVEs for ~/bin being already in the PATH, since it can still contain typos of common commands or commands that are not yet installed (and there is a package kit plugin that shows that people will type commands of packages that are not yet installed), for ~/.i18n (try test -e ~/i18n || echo echo pwned > ~/.i18n if you wonder why), for ~/.ssh/authorized_keys to allow login access for local users or ~/.ssh/config for allowing the ProxyCommand directive. There are endless possibilities here. > the reason not to put . in the path. If there is a directory in the PATH that is controlled by other users, it is very likely a problem, therefore adding "." there is bad. Kind regards Till _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org/message/P3SR4C7RUMRNTRPDMSVRZ6J2WNMDHYM5/
