Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] chrootizing spells into a chroot for secure web serving with thttpd

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Seth Alan Woolley <seth AT positivism.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] chrootizing spells into a chroot for secure web serving with thttpd
  • Date: Thu, 13 May 2004 00:29:50 -0700

On Thu, May 13, 2004 at 08:39:29AM +0200, Vladim?r Marek wrote:
> > > Since there seems to be a long silence, I thought I'd break it with my
> > > latest project. Since I lost my previous chroot environment in a
> > > harddrive crash, I thought I'd try to do it in an automated way this
> > > time.
>
> Great news, possibility to run certain serveces in chroot would be
> really great.

We try to have all services do this by default, and if not, at least use
privilege separation as much as possible. thttpd, ntpd, bind, vsftpd,
sshd, all follow this philosophy. Right now, all services running on my
personal server except apache for a couple php websites are secured in this
manner.

>
> > > I wrote a script that installs spells into a chroot environement from
> > > source cache:
> > >
> > > http://seth.positivism.org/files/chrootize
> > >
> > > http://seth.positivism.org/files/chrootize-example
> > >
> > > It uses the dynamic linking checker ldd to recursively follow
> > > dependencies.
>
> As I went only quickly through your source, it basically means that you
> unpack allready compiled spell from cache to arbitrary directory and
> follow all dll dependencies ?

This is exactly what it does. It gets you to the point that you can
then install sorcery if you wanted and run sorcery completely within the
chroot environment if you so choose. Limited bootstrapping, not a
complete solution like sorcery is.

Once you have sorcery installed, you could rebuild and change your
dependencies, like use xfree86-libs instead of a full X server.

>
> > > I got perl, bash, and GD working in a chroot with the above method. A
> > > clean chroot that needed perl is in the example.
> > >
> > > Just needed to first grab the files: passwd, shadow, group, and
> > > ld.so.conf from /etc and copy them over into the chroot; then run the
> > > mkbusybox script to get a basic cli from your already casted busybox;
> > > then weed out passwd, etc entries for every user you don't need; then
> > > run the chrootize script on what you need; then lastly chroot in and run
> > > ldconfig.
> + delete all unnecessary ld.so.conf entries I would say

Yes, although ldconfig ignores them if there's nothing in them. The
security risk is minimal for having extra directories in there.

>
> > > I then installed thttpd and set it to my chroot directory, gave it a cgi
> > > pattern of '**.cgi' in /etc/sysconfig/thttpd and perl worked like a
> > > charm.
> > >
> > > I just set my htdoc path to be the same as the root for the chroot, but
> > > if you want to hide your chroot files, you can put it anywhere within
> > > the chroot and use thttpd's -dd (datadir) argument.
> > >
> > > Worry about the complexity of securing apache? I find thttpd is so much
> > > simpler to lock down. Then again, no module mess, either (though you
> > > may want to use the 'feature' of apache's modules).
>
> Since I am prividing subversion repository through ssh, I would like to
> chroot ssh and subversion. Do you think it's worth ?

ssh is already privilege separated as much as possible. If you want to
chroot ssh accesses, you could do this, I believe, although I haven't
tried it. One simple way to have ssh chroot after login (instead of
running the daemon within a chroot to begin with) is to set the profile
script of your user shell to run a setuid binary that is able to chroot
and switch back to the user it started under and return exit code 1 when
exiting so as to force a logout. It's a crazy idea, but it might work.
Chrooting the daemon might be easier, but it would require you have
multiple copies of sshd running, possibly on separate ports if you only
have one IP address (might be the safest route since you can have
separate user accounts within the chroot environment).

With a grsecurity patched kernel you can provide much more detailed
control over what happens in a chroot jail.

>
> > and the main reason I installed busybox was to have a working ldconfig
> > ... but if you have glibc installed, ldconfig is installed to /sbin.
> >
> > So you don't even need busybox.
>
> Are you sure you will be able to enter the chrooted environment without
> busybox ? I don't want to copy my whole system to chroot :) Well, best
> is to try myself :)

Yep, it will work fine. A lot of chroot environments have nothing in
them except data files (for example, anonymous ftp servers often used
this trick).

>
> > I might modify the chrootize script to automatically ldconfig the
> > environment and setup the /etc files, although since Hamish's iso work,
> > most of the /etc stuff is handled pretty well automatically.
> >
> > Seth
> >
> --
> Neuron



> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss


--
Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
Key id EF10E21A = 36AD 8A92 8499 8439 E6A8 3724 D437 AF5D EF10 E21A
http://smgl.positivism.org:11371/pks/lookup?op=get&search=0xEF10E21A
Security Team Leader Source Mage GNU/Linux http://www.sourcemage.org

Attachment: pgpYlZOeE3Tvt.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page