From owner-freebsd-security  Sat Jul 13 02:26:39 1996
Return-Path: owner-security
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id CAA25978
          for security-outgoing; Sat, 13 Jul 1996 02:26:39 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id CAA25962
          for <security@freefall.freebsd.org>; Sat, 13 Jul 1996 02:26:27 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id TAA18498; Sat, 13 Jul 1996 19:23:00 +1000
Date: Sat, 13 Jul 1996 19:23:00 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199607130923.TAA18498@godzilla.zeta.org.au>
To: dlowe@best.com, security@freefall.freebsd.org
Subject: Re: dump, rdump
Sender: owner-security@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>  /sbin/dump and /sbin/rdump probably shouldn't be world-executable, as
>they are in the default config of 2.1.0-STABLE.  As far as I know, this
>isn't a root-gaining problem, but any user can use:

>  /sbin/dump 0f $HOME/whatever /usr (or /var)

>and parse the files created for interesting info.  My biggest concern

I think only users in group operator can do this.  Otherwise opening of
the raw disk fails.  It is opened early but after setuid(getuid()).

>  So much for the bug description.  Now my related questions.  From main.c
>in /usr/src/sbin/dump:

>  (void)setuid(getuid()); /* rmthost() is the only reason to be setuid */

>  So it would appear that the program has reverted to the real user-id.
>Why then is it able to read all files on /usr or /var?  And yet can't open

The fd for the disk would remain valid after the setuid(), so dump must be
careful not to open the disk while it is root.  It seems to be careful
enough.

Bruce