At 05:21 PM 12/10/00 +0100, Stas Bekman wrote:
> > At 03:33 PM 12/10/00 +0100, Stas Bekman wrote:
> > >Do you think I should include the scenario of making Apache run in chroot
> > >enviroment in the guide?
> >
> > I think chroot Apache is important especially for dynamic services.
> >
> > >Check out the last section of this article:
> > >Installing and Securing the Apache Webserver with SSL
> > > by Dale Coddington <[EMAIL PROTECTED]>
> > >http://www.securityfocus.com/focus/sun/articles/apache-inst.html
> > >
> > >Of course it's incomplete as it doesn't take into account all the stuff
> > >located under /lib/perl, but it's a good start.
> > I am not sure if this part is so hard. Why can't you copy the the
> /lib/perl
> > to the chroot area and repeat the process everytime you install a CPAN
> module?
>
>Because I'd do all the installation into the chroot area in first place.
>Why keeping track of what should be copied (other than main /lib/lib*
>stuff) when you can install everything into /chroot and maintain it as a
>master (assuming that you have only one mod_perl server).
I suppose you could test an installation of a module on the main Perl and
if it works, then copy /lib/perl to the web server chroot jail itself.
> > If this is not that hard, then you may just want to reference the chroot
> > docs that exist out there. Of course, I could be mistaken about how hard
> > this is.
>
>It proved not to work. I've referenced to a few resources on the web and
>now they all gone dead and I cannot find the new links. So I've these
>tails in the guide where I show results but no sources :( Therefore from
>now on, unless it's something really big and it's known that the info is
>there to stay, I'm integrating the info as is and providing the link to
>the source as long as it's alive.
OK, here's another source you might like. To give credit for notification,
Lyndon Drake sent this one to me last week.
http://penguin.epfl.ch/chroot.html
> > For example, perhaps the mod_perl server and the HTML/images server should
> > be separately chrooted from each other? That way, someone who breaks the
> > dynamic script won't be able to mess with the frontpage of the website to
> > deface it assuming the hacker could get around permissions issues within
> > the chroot jail.
>
>If you have no scripting mods in front end, why would you want to put it
>into chroot at all?
Because it's possible a module you use on the front-end could also be
exploited. For example, if you use mod_rewrite and mod_proxy. If one of
those turns up to have a buffer overflow problem or the like, then someone
could break into your front-end server and you wouldn't want the hacker to
run around the rest of your OS.
> > BTW, OT Question on the subject -- does anyone know if /chroot/etc/shadow
> > necessary once the chroot jail is in effect? The author creates a shadow
> > file but it seemed odd to me. He also advocates copying it over and then
> > creating a new one from scratch which seems redundant and potentially
> > dangerous if the second step is forgotten.
>
>If you don't have the password for httpd user (and you shouldn't have
>one), you probably don't need it at all. I suppose that this scenario was
>copied from the ftp chroot env setup, where it's needed. I think you need
>/chroot/etc/passwd only to get the uid in place. But then you should be
>careful since the main /etc/passwd doesn't know about this secondary
>/chroot/etc/passwd and may give some user the same uid/gid, which is bad.
>I doubt that one need /chroot/etc/passwd and /chroot/etc/group at all.
I think passwd and group get read quite often on-the-fly for permissions.
So I think you would almost always need those no matter what. Again, I
could be wrong on that. I haven't tried it without these files.
Later,
Gunther
