From owner-freebsd-security  Fri Jul 12 17:19:24 1996
Return-Path: owner-security
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id RAA26647
          for security-outgoing; Fri, 12 Jul 1996 17:19:24 -0700 (PDT)
Received: from enteract.com (root@enteract.com [206.54.252.1])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA26642
          for <freebsd-security@freebsd.org>; Fri, 12 Jul 1996 17:19:23 -0700 (PDT)
Received: (from tqbf@localhost) by enteract.com (8.7.5/8.7.6) id TAA19991 for freebsd-security@freebsd.org; Fri, 12 Jul 1996 19:19:21 -0500 (CDT)
From: Thomas Ptacek <tqbf@enteract.com>
Message-Id: <199607130019.TAA19991@enteract.com>
Subject: Permissions
To: freebsd-security@freebsd.org
Date: Fri, 12 Jul 1996 19:19:20 -0500 (CDT)
Reply-To: tqbf@enteract.com
X-Mailer: ELM [version 2.4 PL24 ME8a]
Content-Type: text
Sender: owner-security@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

FreeBSD ships with an awful lot of cruft SUID. 

Typically, my FreeBSD install procedure will involve finding and removing 
SUID from every program on the system, and turning back on the ones I 
need. For a lot of dedicated server installs (where I'm using FreeBSD to 
do things like, say, handle mail, or DNS, or whatever), I tend to turn on 
only two or three of those.

Furthermore, the standard rc file turns on lots of stuff I don't want to 
see running, like lpd and routed. 

The more recent public FreeBSD security problems have been pretty 
stupid. Why was mount_union SUID? Almost nobody I know that runs FreeBSD 
even knows what unionfs is. Likewise, ppp and sliplogin? All the UUCP 
stuff? I'll bet 99% of everyone who installs FreeBSD will never touch UUCP.

It'd be real keen if FreeBSD could be distributed with a script that will 
lock down permissions and rc files for a server install.

As an aside, it'd be very, very, very much worthwhile for someone to go 
through all the FreeBSD code and add bounds checking. There are lots of 
oversights in the source tree. FreeBSD coders have a really bad habit of 
not bounds checking returns from getopt, and not watching the 
environment. A good example, for anyone who wants to see a somewhat hard 
to exploit buffer overflow, is rlogin... try expirimenting with the size 
of the TERM variable.

I've found numerous problems like this in FreeBSD. I'd be very willing to 
help out with security reviews of the FreeBSD code; I think that's a 
worthwhile project, and from what I've read of the code so far, it 
doesn't look like anyone's done that.

Any comments?

----------------
Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com]
----------------
main(){while(1)fork();}