On 2013-10-30 12:25, Reindl Harald wrote:

Am 30.10.2013 11:55, schrieb Alec Leamas:
On 2013-10-30 11:46, Reindl Harald wrote:
Am 30.10.2013 11:27, schrieb Alec Leamas:
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.rei...@thelounge.net> 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
anybody with interests in security

https://www.google.at/search?q=ssh+chroot+why+needs+the+home+directory+to+be+owned+by+root

http://binblog.info/2008/04/06/openssh-chrooted-sftp-eg-for-webhosting/
However, the chroot destination must not be owned by the user for security 
reasons

So you are arguing that $HOME should be owned by root?!
*no i do not*
OK

i gave you a starting point to learn about security and the reason
for sftp-chroot doing so is that someone could use race-conditions
to bypass the security

if you do not understand that allowing any random application running
with your normal user permissions place a binary inside PATH is a bad
idea i really can not help you

security is *always* a process and layered, there are a lot of things
to consider in different levels and while you can not gain 100%
security you can make it harder to bypass restrictions on several
places and doing things which are clearly against is not smart

you can decide taht security is not that important for you
but a distribution as such should not make such wrong decisions for all users
No, it should not. However, the right decision is in many cases a trade-off between security and usabilty, not always with a single answer. Allowing users to install sw (i. e., allowing random applications to put things in $PATH) has of course security implications. Dis-allowing has usability aspects. My personal view is that for the distribution the defaults should allow and support user-installed sw.

And, isn't this still a little off-topic? Current defaults already has ~/bin in $PATH, and user can certainly put things there. Isn't the issue here if having a hidden, writeable directory in $PATH is such a bad idea, given that users actually can install sw?


--alec


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Reply via email to