I did not find any clues when 'googling' and could not find any search options on the archives. So, your answer does really not help. If you can help me with some reference, then it is highly appreciated. I would like to understand the rationaly. Not why 'it is just like it is'. No, why. What is the reasoning behind it. I speak Dutch, English, some Japanese and C. So, I can write something to patch it up in C. But if I do not understand the rationale behind it, what is the value of the writing in any language? If I do not understand the context, that you think I should implicitly understand, what should I do? I can send in a patch if you like. Kind regards, Stephan On 01-05-15 23:42, Damien Miller wrote:> On Fri, 1 May 2015, Stephan Leemburg wrote: > >> Hello, >> >> Is there any security reason why the last component of a chroot path >> is required to be owned by root and not by the user that is chroot-ed >> into that path? > This has been discussed on this mailing list several times in the past. > You should check the archives.
Stephan Leemburg wrote:> I did not find any clues when 'googling' and could not find any search > options on the archives.Try harder: http://marc.info/?l=openssh-unix-dev //Peter
Thank you. I looked through some. If I search on chroot, then I get a lot of things. But no rationale. So, where is the rationale? Where is the rationale behind the fact that the final component of the chroot path should be owned by root? As I already said - and now I also assume you know about all and everything I ever said - I do not see any security risk in the final chroot component being owned by the user if it is not a shared chroot end-path. I cannot find a rationale in the code. I cannot find it on 'the web'. Referring to some mailing lists is not helping. It does not state the rationale. Please explain the rationale behind the safe_chroot path checking. And document it. Why does the final component of the chroot path has to be owned by root? What security issues - that I cannot think of - would arise if it is not owned by root? Can I send in a patch? Just referring people to 'you did not look, go look $maybehere' does not really help. Not receiving an answer would be better than your answer. You seem to have background knowledge. You seem to recall discussions about chroot. Where these discussions also about the _why_ the ownership of the final component of the chroot is supposed to be root? Kind regards, Stephan On 02-05-15 00:23, Peter Stuge wrote:> Stephan Leemburg wrote: >> I did not find any clues when 'googling' and could not find any search >> options on the archives. > Try harder: http://marc.info/?l=openssh-unix-dev > > > //Peter > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
On Fri 2015-05-01 18:23:20 -0400, Peter Stuge wrote:> Stephan Leemburg wrote: >> I did not find any clues when 'googling' and could not find any search >> options on the archives. > > Try harder: http://marc.info/?l=openssh-unix-devThis feels kind of rude. The OP has alreaday stated that he failed at searching, and folks on this list seem to know the answer and not give it to him. This is obviously a FAQ, so we should have a clear and concise writeup about why it is the way it is, maybe with pointers to other details if people want more depth. Here's a point from Jefferson Ogata: http://marc.info/?l=openssh-unix-dev&m=118591826828496&w=2 Here's another variant (slightly different) by Roman Fiedler: http://marc.info/?l=openssh-unix-dev&m=132983579918832&w=2 And another answer by ?ngel_Gonz?lez: http://marc.info/?l=openssh-unix-dev&m=135984176826142&w=2 that last thread has further discussion from Damien Miller as well. The basic concern is that (someone correct me if i'm off-base here) when / is writable, pretty much any deliberate privilege-escalation mechanism (setuid binaries is the obvious example -- are there others?) is likely to be exploitable by whoever can write to /. This is because most tools designed to do limited privilege escalation limit how their increased capabilities can be invoked by some sort of check in the filesystem, whether that's a dynamically-linked binary starting up with a compromised ld-linux.so.2; a modified /etc/shadow, /etc/group, or /etc/fstab, or some other mechanism. Perhaps a brief writeup (feel free to start from the above paragraph if it's not horribly wrong) could be added to the FAQ so that we have someplace concrete to point people the next time this comes up? http://www.openssh.com/faq.html this seems at least as frequently-asked as question 2.4 - "Why does OpenSSH print: Dispatch protocol error: type 20" ;) Happy hacking, --dkg
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
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