https://bugzilla.mindrot.org/show_bug.cgi?id=3715
--- Comment #5 from Joshua Hudson <[email protected]> --- Well CVE-2009-2904 is exactly what would happen if you allowed ChrootDirectory %h to a user-owned home directory on the root filesystem. Back in those days I would have called that a self-inflicted wound as I would have thought the consequences of such a spectacular misconfiguration obvious; but today I've seen too many system administrators who just don't know what hard links are. My plan is to mount the whole filesystem noexec *anyway* so there's that. Even if you manage to link a suid binary into your own home directory, you aren't running it. Thus I write the check as the other guy described; I can reason out that I could in theory allow uploading and running custom binaries and there's no immediate breach of security; but my own decision is to not trust there's not something else awful they can do (like say, kernel exploit) and say no, no uploading binaries for you. -- I tried the alternative of a custom shell to do the chroot process, and even figured out how to get it to exec /usr/libexec/sftp-server from outside the chroot while inside it, but it didn't actually work because that binary isn't statically linked, and of course /lib will be resolved inside the chroot. (glibc doesn't support static linkage for anything other than emergency tools due to the way character sets work...) At this point I'm debating what's the least trouble for the maintenance guy that doesn't involve getting access to hundreds of customer sites all at once for the cutover. -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. _______________________________________________ openssh-bugs mailing list [email protected] https://lists.mindrot.org/mailman/listinfo/openssh-bugs
