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"
signature.asc
Description: OpenPGP digital signature
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct