$HOME/.local/bin in $PATH

[Petr Viktorin]

On 11/01/2013 11:14 AM, Reindl Harald wrote:
>
>
> Am 01.11.2013 11:08, schrieb Petr Viktorin:
>> On 11/01/2013 10:48 AM, Reindl Harald wrote:
>>> Am 01.11.2013 10:38, schrieb drago01:
>>>> On Fri, Nov 1, 2013 at 10:26 AM, Andrew Haley <aph at redhat.com> wrote:
>>>>> On 10/30/2013 10:27 AM, Alec Leamas 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:
>>>>>>>>>> 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.
>>>>>
>>>>> Why does it matter?  A hidden directory in everyone's path is obviously
>>>>> useful to an attacker, and (IMO) more useful to an attacker than to a user.
>>>>
>>>> The attacker needs to be able to write to your home directory to take
>>>> advantage of it.
>>>> And if he can do that (you lost) he has numerous other ways of doing it
>>>
>>> so the people decided not put the current directory in the
>>> PATH on Unix *for security reasons* decades ago must be
>>> fools and if you would have been born as this happened you
>>> would have told them "forget it, in that case you are lost"
>>
>> Was that even for security reasons?
>
> yes, Google may help here
>
>> Anyway, how this is relevant to this discussion? How does a static, well-known (maybe not to you so far) bin
>> directory compare to the danger of . PATH and, say, a rootkit in /tmp/cp?
>
> the rootkit in /tmp/cp is in your path?

If . would have been in $PATH and I happened to be in /tmp, then yes.
On the other hand if I install something in my home, it does not affect 
other users in any way.

(As an aside: the old Unix security decisions assumed the user trusts 
his or her software. This is of course increasingly less the case, but 
that neither makes anyone a fool, nor does it make . comparable to 
~/.local/bin.)

>>> heroic attitude :-)
>>>
>>> *yes* you have lost and in doubt in this situation the
>>> interesting thing is how large the impact becomes
>>
>> Users of a multi-user system get to customize their system without having to bother a sysadmin, and without seeing
>> technical details of that's accompished mixed with their ~/Photos and ~/Documents.
>
> on multi-user systems it is *intentional* that the user does *not* install
> software at it's own and if this should be the case the admin *one time*
> will add a directory to PATH and say "there you go"

As Alec said, not necessarily. If you want this policy for your systems, 
you have the power to do so.
The users (or software they install) can, of course, edit their 
.bash_profile to change it right back.

>> What impact did *you* have in mind?
>
> the *security* impact after "you have lost" happened

In both cases, everything the user had access to is compromised, 
including .bash_profile itself. What other *security* impact did you 
have in mind?

-- 
Petr³