httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@ai.mit.edu (Robert S. Thau)
Subject Re: setuid control WITHOUT running as root
Date Sun, 02 Jun 1996 23:23:15 GMT
  I just see so many holes in the chrooted environment that it is hard to
  distinguish it from the non-chrooted

But do you really need all that stuff?

Actually, one useful thing that might come out of this conversation is
a set of guidelines for setting up a chrooted environment which *doesn't* 
have "so many holes".  I have to confess I actually haven't got much
experience setting up secure chrooted environments, but the things that
occur to me off the top of my head are:

1) Very restricted /etc --- cut-down /etc/passwd without the actual
   password encrypts; *perhaps* cut-down /etc/group and hosts files;
   anything else?

   [Objective: deny attacker potentially useful information to which
   they might otherwise gain access --- password encrypts which might
   be grist for 'crack' in particular, but also crontabs and maintenance
   scripts]

2) No suid files or sgid files (at all --- not even 'ps'; if you want
   to send mail, telnet to localhost on port 25, don't use sendmail).

   [Objective: deny access to suid programs which might have
   exploitable bugs.  We're presuming they can already run code of
   their choice under their own uid, so I'm not sure there's a
   point to eliminating ordinary binaries, but I may well be
   missing something --- binaries whose 'strings' have exploitable
   info about general system configuration perhaps]

3) No device inodes at all, with the *possible* exception of a /dev/null.
   Especially no ptys, ttys, serial lines, tape drives, or disks.

   [Objective: cut back on "terminal answer-back buffer" style attacks,
   or writing out bogus incremental backup tapes which an administrator
   might be sweet-talked into "restoring" later].

4) Main server config files, log files, and maintenance scripts should
   not be in the chrooted area.  No commands which could potentially be
   run from any cron job, or by any maintenance script invoked by a 
   cron job, should be in the chrooted area.  No .htpasswd or .htgroups
   files, or other files with equivalent functionality, should be in the
   chrooted area.  Whatever ordinary commands or lib files *are* in the
   chrooted area should be duplicates, not hard links.

   [Objective: if they can't see it, they can't futz with it.  Also,
   make it hard to plant trojan horses]

There have got to be more rules than this --- what am I missing?

rst

Mime
View raw message