[ On Mon, November  7, 1994 at 16:58:56 (-0500), Chris G. Demetriou wrote: ]
> Subject: Re: chown, quotas and security 
>
> I wasn't quite sure of all the fun implications of making chown()
> legal for non-root users.  here are some fun ones:
> 	(1) somebody doesn't have a mail spool file, on a system where
> 		the mail spool directory is mode 1777.  i create
> 		a mail spool with their name, give it permissions
> 		such that i can read it, and chown it to them.
> 		(note that 1777 mail spool dirs aren't the default
> 		in NetBSD, but some people prefer them; this isn't
> 		a straw man.)

Preference is no excuse for ignorance.  So I "prefer" /bin/sh to be
world writable.  Should someone add code to various things to make sure
root doesn't run a compromised shell?

I.e. I don't think this argument has a snowball's chance in hell.

> 	(2) certain editors (vi, ex) will use a "local" configuration
> 		file, if it exists in the current directory and is
> 		owned by the invoker of the editor.
> 		echo a_fun_ex_command > /tmp/.exrc ; chown root \
> 			/tmp/.exrc 
> 		INSTANT TIME BOMB!

Again, fix the silly editor (and in this case the sysadmin too!).

> unless i'm presented with _very_, _very_ strong motivation for
> allowing chown() to normal users, in my opinion this presents too
> large a set of potential holes to be allowed.  I don't think i'd even
> entertain the idea of allowing the sysad to set up the standard
> chown(8) (e.g. by making it set-id, or something) to allow users
> to give away files.

I continue to say a setuid chown(8) is a bad idea.  However, a careful
chown(2) isn't a bad idea at all -- in fact it's a very useful feature.

I think the Doug Gwyn quote posted by Greywolf earlier in this thread
applies 110%, so I'll repeat it:

    "UNIX does not stop you from doing really stupid things, because
     then UNIX would be stopping you from doing really clever things."
 							-- Doug Gwyn

BTW, anyone know what FIPS-151 has to say about the preferred or default
value of _POSIX_CHOWN_RESTRICTED?  Does anyone care if NetBSD could be
made to conform to FIPS-151?

[[ Note, there's a very similar debate I got into once about why it
should be illegal for a process with effective uid = 0 to setuid(N)
where N!=0, and then hope to setuid(0) again.  Luckily the existance of
the /proc filesystem with user-writable core maps makes this argument so
much easier to make!  The moral of the story is that you have to give up
some questionable features in order to make careful use of some really
powerful (and thus dangerous) features, esp. when those questionable
features make the powerful feature un-restrictably dangerous. ]]

-- 
						Greg A. Woods

+1 416 443-1734			VE3TCP		robohack!woods
Planix, Inc. <woods@planix.com>; UniForum Canada <woods@uniforum.ca>