sftp chroot requirements

[Stephan Leemburg]

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 at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev