[Bug 3715] safely_chroot is a little too restrictive: noexec or nosuid should be enough

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=3715

--- Comment #5 from Joshua Hudson <joshudson at gmail.com> ---
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.