[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Chroot jail



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
> > 
> nyh@math.technion.ac.il             |-----------------------------------------
> > 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 linux-il-request@linux.org.il with
> > the word "unsubscribe" in the message body, e.g., run the command
> > echo unsubscribe | mail linux-il-request@linux.org.il
> >
>
>--
>
>         Shaul Karl <shaulka@bezeqint.net>

--
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 linux-il-request@linux.org.il with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail linux-il-request@linux.org.il