Path: utzoo!mnetor!uunet!yale!husc6!bu-cs!bzs
From: bzs@bu-cs.BU.EDU (Barry Shein)
Newsgroups: comp.unix.wizards
Subject: Re: Remote dumps as root (was Re: Why does "root" worn everything?)
Message-ID: <20725@bu-cs.BU.EDU>
Date: 18 Mar 88 02:59:44 GMT
References: <5209@uwmcsd1.UUCP> <9269@sunybcs.UUCP> <7454@brl-smoke.ARPA> <9926@steinmetz.steinmetz.UUCP> <9318@sunybcs.UUCP> <1610@pinney.munsell.UUCP>
Distribution: na
Organization: Boston U. Comp. Sci.
Lines: 32
In-reply-to: pz@munsell.UUCP's message of 17 Mar 88 01:04:50 GMT



>I asked Sun what to do about this.  (Isn't software support wonderful)
>They just told me to make /etc/dump setuid root, setgid operator.
>None of my backups are done by someone logging in as root.
>
>Was this stupid?
>
>					pZ

Given that and an unprivileged account I could read any file on your
workstation and probably own it in a few minutes if I thought about it
a little (consider the effect of dump 0f /etc/passwd filesys, or
something along those lines.)

If you're not worried about such things, or the user gaining access to
all local files (it may not be of much use across nfs, tho it could be
a first step in a multilevel attack) then there's not much to worry
about, it depends on how hostile your environment is. Of course, they
could wipe out a file or file system inadvertantly, like specifying
the args in the wrong order, root privs are like that.

You might instead consider writing a little setuid C program that only
does exactly the right thing, providing all dump args etc or perhaps a
limited menu of choices, then forking it, but not free choice such as
specifying any output file on the command line. I'm not sure that
would be completely secure (what harm can you do from a dump prompt?)
but it may be close enough and it should only be a page of C code, you
may have to be as imaginative as your imagined attacker. You might
consider putting it execute-only onto a remote NFS partition, if you
allow remote setuid root programs.

	-Barry Shein, Boston University