Hi, At 04:50 11/10/01 +0200, you wrote: > > On Wed, Oct 10, 2001, Eran Levy wrote about "Chroot jail": > > > Hi, > > > I know how making bind, apache, etc. into a chroot jail. But now I > want to > > > make a guest account in a chroot jail. I had some documents/guides about > > > that, but I cant find them now. Can someone give me URLs of > > > documents/guides? I cant find guides/document specified for a user > account > > > in a chroot jail. Any idea? > > > > I don't know of any guides (try a search engine like Google) but there's > > one obvious problem you'll need to solve when chroot-jailing someone: > you'll > > need to provide a copy all the binaries, libraries, and so on that the > user is > > supposed to use inside his jail. This becomes unwieldy when you have > several > > jailed users. > > Two ways to prevent this redunant copying: > > 1. Use hard-links (symbolic links won't work) rather than copying > > 2. Put all the binaries, libraries, etc., that you want to give your > > users in a seperate partition, and then mount it at multiple mount > points. > > This is possible in Linux! You can even have a virtual partition (e.g., > > some sort of loopback) and not a real disk partition. > > > > But if you use one of these solutions, watch out: one of the ideas of a > > chroot jail is that the user may (through some exploit) become root, but > > then can only ruin his own files. If the files are linked to other files, > > he'll be able to ruin those files. So never link a non-trusted user's files > > with the ones you're using - always make at least one other copy - for the > > non-trusted jailed users. > > > > Another point to note: if the jailed user has access to /dev/kmem, > /dev/hdc1, > > and various tricks in /proc, he *will* be able to write outside his limits. > > So generally it is not safe to have a full /dev, or even procfs, in the > > chroot jail. This will screw some of the normal Linux applications so > > watch out. > > In addition, you will need to figure out how to prevent the jailed users > > from adding kernel modules to your kernel (and in this way bypassing all > > security!). Removing the "insmod" binary is obviously not enough, but I'm > > not sure what is. You may need to compile a kernel without modules, or > > better yet lock out all new modules after the boot loaded the ones you > > need (I saw once a module that does that, I don't remember which). > > > > In short, a good chroot jail for shell users is very hard to pull off... > > > > >Have you consider having this account with a restricted shell? >
I have thought about it, but I don't want it because of few reasons. Nadav, Tzaffrir, Illya and Shaul, Thanks for the help and the detailing messages. > > > > -- > > Nadav Har'El | Thursday, Oct 11 2001, 24 > Tishri 5762 > > > [EMAIL PROTECTED] |----------------------------------------- > > Phone: +972-53-245868, ICQ 13349191 |Hardware, n.: The parts of a computer > > http://nadav.harel.org.il |system that can be kicked. > > > > ================================================================= > > To unsubscribe, send mail to [EMAIL PROTECTED] with > > the word "unsubscribe" in the message body, e.g., run the command > > echo unsubscribe | mail [EMAIL PROTECTED] > > > >-- > > Shaul Karl <[EMAIL PROTECTED]> -- Best Regards, Eran Levy. "This is Linux country. If you listen carefully, you can hear Windows reboot..." WebSite: http://levy.dyn.dhs.org ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
