From owner-freebsd-security  Thu Jan 25 07:21:59 1996
Return-Path: owner-security
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id HAA26065
          for security-outgoing; Thu, 25 Jan 1996 07:21:59 -0800 (PST)
Received: from gateway.fedex.com (gateway.fedex.com [198.80.10.2])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA26060
          for <security@freebsd.org>; Thu, 25 Jan 1996 07:21:55 -0800 (PST)
Received: by gateway.fedex.com id AA04710
  (InterLock SMTP Gateway 3.0 for security@freebsd.org);
  Thu, 25 Jan 1996 09:17:10 -0600
X-Disclaimer: THE COMMENTS CONTAINED IN THIS MESSAGE REFLECT THE VIEWS OF THE
                         WRITER AND ARE NOT NECESSARILY THE VIEWS OF
                                 FEDERAL EXPRESS CORPORATION.
Message-Id: <199601251517.AA04710@gateway.fedex.com>
Received: by gateway.fedex.com (Internal Mail Agent-2);
  Thu, 25 Jan 1996 09:17:10 -0600
Received: by gateway.fedex.com (Internal Mail Agent-1);
  Thu, 25 Jan 1996 09:17:10 -0600
X-Authentication-Warning: dpd08.dpd.fedex.com: Host localhost didn't use HELO protocol
To: Paul Richards <p.richards@elsevier.co.uk>
Cc: security@freebsd.org
Subject: Re: bin owned files 
Date: Thu, 25 Jan 1996 09:19:23 -0600
From: William McVey <wam@fedex.com>
Sender: owner-security@freebsd.org
Precedence: bulk

Paul Richards wrote:
>Therefore, the only way to get root access from
>bin is to replace, say, /bin/sh with a program that creates a suid root
>sh *when it is run by root*.

Which occurs whenever cron executes something on behalf of root.  How
about all those executables owned by bin but run by root from within
inetd?  How about init?  or /bin/login (which may not be owned by bin,
but is in a bin-owned directory, so is therefore exposed).

>If you log in as root and don't realise that
>there has been a compromise of bin then that is your problem but in and
>of itself a bin compromise is safer than a root compromise for the
>reasons I previously explained.

There have been several examples given where the real administrator
plays no role in running the trojan horse... running executables is
a system function root performs all the time, not just during interactive
login sessions.

>All other arguments relate to NFS and I refuse to even discuss NFS in this
>context. If you crack root anywhere on an NFS system then the whole
>system is compromised and while making things owned by root makes it
>a little harder it is no protection. I can masquerade as many other users
>and find other ways to do what I want. The whole point is, there *was*
>a root break-in, the fact that it wasn't the actual server box is not an
>issue. NFS cannot be regarded as a number of separate machines from
>a security context, a compromise on one is a compromise on them all.

No, this is not necessarly the case.  I was an administrator for a lab
of 200+ workstations with NFS mounts from a few central file servers.
A compromise on one the workstations (in a public lab with few real
physical security precautions) did *NOT* result in a compromise of the
servers.  The clients were considered expendible since they were reloaded
every semester.  User data was at risk, but this was well known and 
instructors were informed to not keep sensitive data on the lab cluster.

 -- William