On Sat, 8 Dec 2001 15:18:41 -0500, Chris Wright wrote > * Jacques Gelinas (jackat_private) wrote: > > No. This has been tested. Since 2.4.10, all tests we did failed. > > cool, thanks for the correction. i wasn't very clear, and meant > chroot(2) can be broken. the reason is chroot(2) does not change the > cwd. but, vserver is using chroot(1) which includes the proper > chdir(2). sorry for the confusion. No this is what I was talking about (the system call). There are two ways to break out of a chroot environment. One is to open the device (/dev/hda) and dig your way in the file system "by hand". vserver do not have those special files and are not allowed to create them. the other solution is to slide the carpet under your feet(tm) :-) You keep your current directory and do a chroot in a sub-directory. Then your current directory is out of scope, compared to the new root. So you are free to chdir("..") to the real root. Another solution is to open a directory (using open system call), keep the handle and perform the chroot. Then you use fchdir() to change to this directory, again outside of the new root. So you are free to move to the real root. In the vserver source, you will find a file tests/escaperoot.cc which test both case. The nice thing is that since 2.4.10, all tests failed. I would say that chroot(2) is not reversible, whatever you do with your current working directory. I strongly believe that chroot has to be that way. This is a simple system call and this is what people expect (not breakable). So if you think we have missed a way to escape out of a chroot(), please tell me and we will make sure the kernel is fixed. > > > - i don't like that it touches ext2 and ext3 directly. this makes it > > > brittle w.r.t. filesystems (something we specifically don't do in LSM). > > > > No way out if we want to have a workable unification with hard links. > > yes, i agree. but unification has the problem of hard links, meaning all > vservers have to be in same mount point. this seems like a limitation > to me. it would be nice if read-only wasn't limited to per-superblock > such that you could effectively mount -o ro --bind. i know you didn't > like the granularity limitations of this directory based approach. > of course, w/out extended attributes you do have to jump through some > hoops to get file level granularity, and i appreciate the simplicity > and effectiveness of vserver. Another solution would be to use LVM and its snapshot mecanism. Call it "instant vservers". I have not tried it though. --------------------------------------------------------- Jacques Gelinas <jackat_private> vserver: run general purpose virtual servers on one box, full speed! http://www.solucorp.qc.ca/miscprj/s_context.hc _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Mon Dec 10 2001 - 09:47:42 PST