There are no differences with respect to the underlying kernel state.
There is a minor difference with respect to the operation of the mount command: it keeps track of its actions in /etc/mtab, so running mount under chroot will update a different mtab file.
You could also use mount --bind /proc ./my_chroot/proc. As far as I know, there is no practical difference between that and mount -t proc none ./mychroot/proc: you can mount the proc filesystem as many times as you like, and mount options are ignored. mount --bind will prevent you from unmounting the filesystem on /proc outside the chroot, but that should never happen anyway.
As an aside, I would recommend mount -t proc proc …/proc because seeing proc in the device field in a mtab or in /proc/mounts is clearer than seeing none.
The only FHS-mandated directories that are commonly world-writable are /tmp and /var/tmp. In both cases, that's because they are intended for storing temporary files that may be made by anyone.
Also common is /dev/shm, as a tmpfs (filesystem backed by RAM), for fast access to mid-sized data shared between processes, or just creating files that are guaranteed to be destroyed on reboot.
There may also be a /var/mail or /var/spool/mail, and sometimes other spooler directories. Those are used to hold mail temporarily before it's processed. They aren't always world-writable, depending on the tools in use. When they are, it's because files can be created there by user tools for processing by daemons.
All of these directories usually have the sticky bit (t) set, meaning that only the owner of a file or of the directory can move or delete the files in it.
Any program running as any user can make files in these directories, and it's up to the creating program to do the right thing as far as security for its particular data goes. There's no particular general security problem other than someone potentially filling up the filesystem, but plenty of scope for a program to get it wrong.
There have been some moves towards service-specific /tmp directories. These avoid some of the potential bugs that can come up, so it's not as vital for the program to be bug-free in how it uses the directory.
You can find the world-writable directories on your system with:
find / -maxdepth 3 -type d -perm -777
Best Answer
The attack here is commonly known as the "Roaring Beast" attack; you can read more about it in these bulletins:
In order to use the
chroot(2)function, the FTP server must have root privileges. Later, the unprivileged client requests the creation of files within/etc(or/lib) within that chrooted server process. These directories usually contain dynamically loaded libraries and configuration for system libraries like the DNS resolver, user/group name discovery, etc. The client-created files are not in the real/etc/and/libdirectories on the system -- but within thechroot, these client-created files are real.So the malicious client connects to an FTP server which chroots their process, they create the necessary
/liband/etcdirectories/files within that chroot, upload a malicious copy of some dynamic libraries, and then ask the server to perform some action that triggers the use of their new dynamic libraries (usually just a directory listing, which leads to using the system functions for user/group discovery, etc). The server process runs that malicious libraries, and because the server might still have root privileges, that malicious library code can then have extra access to do whatever it wants.Note that
/etcand/libare not the only directories to watch; the issue is more about the assumptions made by system libraries about their file locations in general. Thus different platforms may have other directories to guard.ProFTPD, for example, now bars the creation of such
/etc/and/libdirectories when chrooted, to mitigate such attacks.