Xref: utzoo comp.unix.admin:1904 alt.security:2594
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!convex!usenet
From: tchrist@convex.COM (Tom Christiansen)
Newsgroups: comp.unix.admin,alt.security
Subject: Re: setuid (was Re: Non Destructive Version of rm)
Keywords: setuid risks
Message-ID: <1991May21.121555.5087@convex.com>
Date: 21 May 91 12:15:55 GMT
References: <9105130857.aa02726@art-sy.detroit.mi.us> <1991May14.101450.830@convex.com> <9105200808.aa02147@art-sy.detroit.mi.us>
Sender: usenet@convex.com (news access account)
Reply-To: tchrist@convex.COM (Tom Christiansen)
Distribution: na
Organization: CONVEX Software Development, Richardson, TX
Lines: 30
Nntp-Posting-Host: pixel.convex.com

From the keyboard of chap@art-sy.detroit.mi.us (j chapman flack):
:The man page mentions that on "some" systems pwd(1) does not run setuid-root
:and so can't pwd if the parent or an ancestor directory is unreadable.
:
:My system is one of those.  Is there something intrinsically unsafe about pwd
:that would create holes if I made it setuid-root?

I can't really think of anything, but this is scant evidence, let alone
proof, of trustworthiness.  Most of us seem to get by find without a suid
pwd(1).  It fails whenever a normal getwd(3) would fail, but few of us
consider this critical.  So what?  The fewer suid programs (and the fewer
programs root always runs) the less you have to worry about.  And I don't
think implementing getwd(3) via a popen(3) to a suid pwd(1) is a very
elegant solution.

:Also, I'm not sure I understand the effect of the resource-depletion types
:of attacks.  Someone recently suggested by email that a program can be made
:to crash and leave the user in a privileged shell.  When a program bombs,
:doesn't its (privileged) process disappear?

I've heard people say this, too, but it makes little sense.  All I 
can imagine is that the program might be coerced into giving you 
a NEW, interactive, privileged shell.  It would have to be a very
naughty program to change the uid/gid privs of its calling process,
although as I've shown before, it can be done if you poke kmem.

--toim
--
Tom Christiansen		tchrist@convex.com	convex!tchrist
		"So much mail, so little time."