$HOME/.local/bin in $PATH

[Miloslav Trmač]

On Wed, Oct 30, 2013 at 10:23 AM, Reindl Harald <h.reindl at thelounge.net> wrote:
>> 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/
>
> there are three type of users
>
> * people who care about security and know that there are
>   enough rough edges but smart enough to take this *not
>   as excuse* to create new ones

That's not how security works.  To get actual security, you want the
design to make a _precise_ promise, and then implement it _100%
correctly_.  Not with "rough edges"; compose three implementations
with "rough edges" and the result gives you no security promise.

In this case, the security promise needs to be "the attacker can't
write to arbitrary files in your home directory"; if that is broken,
the existence of ~/.local/bin doesn't make any difference.


I agree ~/.local/bin is problematic for system administration and
troubleshooting, but that's not security.  And yes, the design is
known to have problems (multi-arch in shared home directories, same as
~/bin) - but now that it has been there for some time, we really can't
remove it without breaking user's existing setups, so it would need an
_extremely_ good reason.
    Mirek