$HOME/.local/bin in $PATH

[Reindl Harald]

Am 01.11.2013 13:00, schrieb Petr Viktorin:
> On 11/01/2013 11:14 AM, Reindl Harald wrote:
>> 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.)

and because it is increasingly less the case we shoulkd be *very*
careful in extending PATH environment

>> 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

which works also in the other direction and users knowing about $HOME/.local/bin
most likely know about .bash_profile

> The users (or software they install) can, of course, edit their .bash_profile to change it right back.

if you really want to forbid it strictly they can't
chattr +i .bash_profile; chattr +i .bashrc

but we are talking about defaults

>>> 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?

when i learned something about security than that the dangerous things are the
one which are *not* in your mind and that is why the environment should be
as tight as possible

example from the server world?

* vhost with no vulnerable scripts
* another vhost with a file inclusion vulnerability
* no open_basedir set in the vulnerable one
* attacker called a page with <?php code ?> in the URL and wrote "his script"
* file inclusion vulnerability to the apache access log
* the so executed code modified scripts in the non vulnerable vhost
* later they placed PHP code in images
* http://www.phpclasses.org/blog/post/67-PHP-security-exploit-with-GIF-images.html
* finally they removed their scripts but made a mistake which was the only reason the
  forensic found what happened on the machine

i was not responsible for the server itself, but for the not vulerable CMS and
had to prove that not my CMS was the door for compromise the server and after
we found out what exactly happend i had to say "wow, respect"

*that* is what happens in security if someone comes with "show me the exact problem you see"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20131101/a1a2b442/attachment.sig>