On Wed, Oct 30, 2013 at 6:27 AM, Alec Leamas <leamas.alec@xxxxxxxxx> wrote: > On 2013-10-30 11:23, Reindl Harald wrote: >> >> Am 30.10.2013 11:20, schrieb Alec Leamas: >>> >>> On 2013-10-30 10:58, Reindl Harald wrote: >>>> >>>> Am 30.10.2013 10:53, schrieb Alec Leamas: >>>>> >>>>> On 2013-10-30 10:23, Reindl Harald wrote: >>>>>> >>>>>> Am 30.10.2013 02:03, schrieb Chris Adams: >>>>>>> >>>>>>> Once upon a time, Reindl Harald <h.reindl@xxxxxxxxxxxxx> said: >>>>>>>> >>>>>>>> [root@srv-rhsoft:~]$ mkdir test >>>>>>>> i could rm -rf ~/ here >>>>>>>> >>>>>>>> [root@srv-rhsoft:~]$ cat /usr/local/bin/mkdir >>>>>>>> #!/bin/bash >>>>>>>> echo "i could rm -rf ~/ here" >>>>>>> >>>>>>> If I can write to files you own, it doesn't matter if there's a >>>>>>> directory in the PATH or not. I can write this to your >>>>>>> .bash_profile: >>>>>>> >>>>>>> /bin/mkdir $HOME/.bin 2> /dev/null >>>>>>> echo 'echo "i could rm -rf ~/ here"' > $HOME/.bin/mkdir >>>>>>> chmod +x $HOME/.bin/mkdir >>>>>>> PATH=$HOME/.bin:$PATH >>>>>> >>>>>> you can do this and that - but that's no valid argumentation >>>>>> doing bad things in default setups and *at least* do not >>>>>> place *hidden* diretories there, ther is a good reason why >>>>>> software like rkhunter alerts if you have hidden directories >>>>>> somewhere in /usr/bin/ >>>>>> >>>>> Some kind of reference for the bad in having a well-known, hidden >>>>> directory in the path? >>>> >>>> the *writeable for the user* is the problem >>> >>> Any reference for this problem? >> >> what about consider the implications? >> do you really need a written reference for any security relevant fact? >> i can write one for you if you prefer links :-) >> > Well, the question is really if someone else out there share your concerns > about this. I share them, and I agree that it is the argument, not a citation, that demonstrates the merits of the security case. Supporting user-installed software in $HOME is a fine goal... but it shouldn't be done in a way that puts user-installed software earlier in the path by default, or expanding the number of points for users to watch for bad-behaving apps. As a long-time user of Fedora, I'd have never even thought of checking for executables in ~/.local/bin, until I happened to read this thread... and when I did, it was quite unnerving. The one reprieve from all this, is that, when I checked, it was later in the path than the system paths (at least for me), not earlier, as was previously asserted in this thread. Of course, one can always check the contents of $PATH directly... but there's some level of trust here... because that can get quite long, and lazy users like me assume (perhaps badly) that if we didn't modify it in our login scripts, it wasn't modified to include any additional user-writable paths beyond ~/bin And, the xdg argument doesn't seem like a sufficient argument for me... we're talking about login scripts, not X. It is very unintuitive that an xdg-related directory would be on the default path for a bash login, if you're not even running X. This is a bash profile... not an X profile... The biggest problem isn't that it's hidden or that it's there by default, or that it's writable by potentially bad-behaving software. The biggest problem is simply that users don't know about it. I certainly didn't. -- Christopher L Tubbs II http://gravatar.com/ctubbsii -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
