[ On Friday, December 1, 2000 at 04:55:24 ( +0900), Noriyuki Soda wrote: ]
> Subject: Re: Addition to force open to open only regular files
>
> But original 4.4BSD developers didn't think so, that's why 4.4BSD semantics
> are different from POSIX semantics.
> And Charles M. Hannum, Matthew Green and other NetBSD developers don't
> think so, either.

Show me the code where it matters.

(and I can probably show you a way of doing the same thing without
encountering any problems and without too much added cost to make it
impractical)

So far nobody has offered any examples of requirements which make the
4.4BSD semantics necessary, and yet we've all seen the very real dangers
of this way of doing things.

So far as I've ever been able to discern the *BSD "enhancements" to
set-ID are only a cheap and easy way of getting around some thorny
issues, and they do it at obvious risk.  The attempt at reducing the
risk by re-defining setre*id() into sete*id() is clearly not enough of a
reduction to improve the security of the system.  I.e. it did not "raise
the bar" significantly.

> > Su only uses setuid(), not seteuid() or setreuid().  I've never
> > seriously proposed changing setuid(2).
> 
> If you won't change setuid(2), buffer overrun attack is still possible,
> thus, open_as() didn't make system secure.

Yes, it will.  :-)

I've already gone over the reasons why and how several times (though
perhaps not yet with the clarity such a description deserves).

Naturally the set-ID programs in question must still make use of
setuid(), but I believe from my experience and recent research that
forcing set-ID programs to do without seteuid()'s ability to regain
privileges will make it much easier for such programs to choose an early
point at which to call setuid(getuid()).

Given sufficient time and resources I will prove this with working code,
but at this point all I can do is hope to show others that it is
possible to "raise the bar" much higher than it currently sits against
the leap of a cracker and thus to maybe share the load of making it so.

You can audit and test sensitive code all you want, but unless you
re-audit and re-test after each and every change with a verifiably
repeatable software process that takes into account all newly discovered
vulnerabilities and weaknesses, you don't really get any further ahead
either.  However I believe that by making the underlying system design
more amenable to safe programming practices that you will gain a
permanent improvement in security.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>