[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Chroot jail
> 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?
>
> --
> 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>
=================================================================
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