Hi Damien,
Thank you. I read the rationale.
Just to summarize, a user writeable chroot target is considered
dangerous if:
1) the user has another way of gaining non-chrooted access to the system
2) is able to create hardlinks to setuid-binaries outside of the chroot tree
3) there are bugs somewhere that allow privilige escalation or remote
execution of other programs
While all these arguments are legitimate, as can be - indeed - seen in
CVE-2009-2904, I believe that there are also other situations.
In our setup, we have users that currently only have vsftpd chrooted
access. Their login shell is /sbin/nologin and they do not have any
other way of accessing the system. So for this particular setup 1 and 2
are not applicable.
I think 3 is not related to sftp chroot only, but in general.
So, in my opinion there are use cases that would not compromise security
by having the last component of the chroot sftp directory be owned by
the user.
If this could be a configurable option, then administrators that want to
use such a setup could do so by explicitly allowing it.
Is that something you could live with? If so, can I create a patch and
send it in?
Again, thank you for the pointers. I had trouble finding them with just
plain search engine lookups.
Kind regards,
Stephan
On 02-05-15 07:14, Damien Miller wrote:
On Fri, 1 May 2015, Stephan Leemburg wrote:
I did not find any clues when 'googling' and could not find any search options
on the archives.
http://marc.info/?t=122641302700006&r=1&w=2
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
