From owner-freebsd-bugs  Sun Mar 23 21:19:37 1997
Return-Path: <owner-bugs>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id VAA27115
          for bugs-outgoing; Sun, 23 Mar 1997 21:19:37 -0800 (PST)
Received: from spinner.DIALix.COM (root@spinner.dialix.com [192.203.228.67])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA27110
          for <freebsd-bugs@freebsd.org>; Sun, 23 Mar 1997 21:19:26 -0800 (PST)
Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1])
          by spinner.DIALix.COM (8.8.5/8.8.5) with ESMTP id NAA10729;
          Mon, 24 Mar 1997 13:19:11 +0800 (WST)
Message-Id: <199703240519.NAA10729@spinner.DIALix.COM>
X-Mailer: exmh version 2.0gamma 1/27/96
To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
cc: freebsd-bugs@freebsd.org
Subject: Re: sendmail can't create PID file because of owner permission of /var/run 
In-reply-to: Your message of "Mon, 24 Mar 1997 00:08:00 +0100."
             <19970324000800.WG00772@uriah.heep.sax.de> 
Date: Mon, 24 Mar 1997 13:19:10 +0800
From: Peter Wemm <peter@spinner.DIALix.COM>
Sender: owner-bugs@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

J Wunsch wrote:
> As Ollivier Robert wrote:
> 
> (System directories owned by root.)
> 
> > Some people (including me) have been asking for this change for *years*.
> > Please someone do it !
> 
> Some other people (including me) still believe that tweaking all
> systems just because some people suffer from NFS's flaws is not doing
> better either.
> 
> Those who suffer from NFS know how to use chown -R...  NFS-exporting
> something writable to any machine you can't trust gets you what you
> deserve.

I mentioned NFS "for example".  Having the entire system writeable by uid 
bin means that the system can easily be compromised by the "bin" account, 
as well as root.  From my subjective observations, 99% of system security 
analysis seems to be focused on protecting root - "bin" seems to get 
rather little scrutiny.  Yes, there are other uid's (eg: uucp, games), but 
they can't get to things commonly run by root (eg: /bin/sh, /bin/ls etc).  

IMHO, the only thing that is gained by having stuff uid bin is that the 
scope of vulnerability is increased to a non-root uid as well.

Saying "use chown -R" isn't a good answer, because the build system goes 
to great pains to restore the security problems! (also, chown -R is deadly 
on the system directories..  What about setuid-uucp programs that become 
setuid-root?)

Cheers,
-Peter