[ On Sat, June 7, 1997 at 09:15:20 (-0500), Peter Seebach wrote: ]
> Subject: Re: File names and security...
>
> My main problem with the canonical behavior is that there are scripts
> I simply can't write to be efficient using it.  :(

There's nothing new about that.  All that's changed is the level of
trust you give your users and the resulting risk assesment.

It has always been the case that computer systems in general require a
high degree of attention when used in high risk environments.  Changing
the design to be more preemptively careful about risky things is one way
to provide that level of attention, but changing the design of unix at
this point is invention that we just don't need.

I just had a thought regarding trusted systems and privileged users that
might make this issue a little easier to swallow.

What if there were a sysctl that would do something like the following
for every non-set-user-id exec():

	if (!exec_with_priv_ok && (geteuid() == 0 || getuid() != geteuid())) {
		if (getuid() != 0)
			setuid(getuid());
		else
			setuid(UID_NOBODY);
	}

The exec_with_priv_ok flag would be a new extension to the exec() family
for use by setguid programs that wish to pass on their privileges to a
child process.  It could in fact be the value of the new sysctl flag by
default.

Something similar might even be possible for group privs where getegid()
doesn't occur in getgid() or getgroups().

With this feature turned on a paranoid admin would not have to worry
about privileged programs or users wandering into code that's not
prepared to protect them.  The only trick is somehow identifying shell
scripts that have been coded as one would code a setuid program.  It
would have to be something inside the code which enables this attribute,
so perhaps a new shell built-in to set the exec_with_priv_ok bit on a
per command basis.

Every setuid() program and everything used by root to do admin tasks
would have to be checked and the appropriate flags added to exec() calls
that need them and of course all the exec()ed code would also have to be
checked, but this would be a small hidden and completely optional change
as compared to completely nuking the filesystem semantics even on an
optional basis.

-- 
							Greg A. Woods

+1 416 443-1734			VE3TCP			robohack!woods
Planix, Inc. <woods@planix.com>; Secrets Of The Weird <woods@weird.com>