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.reindl@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
