In order to avoid copying all the shared libraries and config files into the chroot folder, I plan to call chroot("path/to/folder"); right after all the shared libraries and config files have been loaded.
Would a buffer overflow exploit in the previously loaded libraries provide the attacker access outside the chroot? (Because they were loaded before chrooting.)
Are there any drawbacks to this delayed chroot method in comparison to chrooting before program execution?
Shared libraries are loaded into your executable's process space, and have exactly as many privileges as your executable. As soon as your executable is chrooted, so are they.
Delayed chrooting isn't necessarily a good idea for executables that are run setuid/setgid, and are meant to be hardened against local attacks, because the sorts of things they access before they chroot (command-line arguments, configuration files) are exactly the sorts of things that would be exploitable. That goes for shared libraries too, I suppose. But if you're, say, mitigating the potential vulnerabilities of a networked server process, delayed chroot offers you the best of both worlds.
It's a relatively remote possibility, but the libraries you load may open files/directories, create threads, etc. as soon as you load them (source). This means there may be handles open to things outside the chroot that could be abused in the event of an exploit.
