[ On Thursday, November 23, 2000 at 23:07:26 (-0700), Warner Losh wrote: ]
> Subject: Re: Addition to force open to open only regular files 
>
> Without seeing a good API on open_as, I'm inclined to agree.  Even
> with a good API, I'd be inclidned to agree.  There's no way to get the
> saved id's that people would want to use with the parameter to the
> open_as call.  At least not in a library.  I've not seen how this can
> be done in this thead unless theres a getsuid() and a getsgid() system
> call added as well.  And if there is, one can always do the seteuid()
> trick that soda-san has been talking about, unless the process has
> used setreuid() to do its ID swapping, in which case you can't do the
> id swapping.

It's not, at all, necessary to get the saved-set-ID value.  The real-ID
is *always* the correct one to use from within a library routine that
wants to safely open an arbitrary pathname, regardless of whether the
calling program was set-ID or not, and regardless of whether or not the
calling program had first called setuid() or not.  Why is this
apparently so hard to understand?  It should be trivially obvious!

> People seem to want an access(2) like system call that is really an
> open_with_saved_id() rather than an open_as() since you'd want to
> restrict the open_as semantics to only be a few select uids.

Actually no, that's not what's necessary.  An open_as_real_id() would be
closer to what's really necessary though.

Of course nothing new or different is necessary if you're willing to
live with the dangers of saved-set-ID swapping....

The ability I suggest of using the saved-set-IDs in open_as() is only an
added feature that would make it possible to do things that programs
such as sendmail or smail, cron, calendar, etc. might want to do without
forking.  Obviously this isn't a necessary feature if you're willing to
deal with forking and possibly other complications.  However as is
evident by examining the complexity of my fopen_as_user() function in
smail-3, it would make one hell of a lot more sense to put such a
feature directly in the kernel where it might be a *lot* smaller and
simpler [and where of course it will avoid a double open() and a
fork()].  Obviously such a feature isn't 100% safe, but I argue that it
is safe enough to ensure that exploit attempts can be detected and
repaired before they are successfully used.  Further debate on the
latter issue is certainly welcome, of course.

>  If you
> open the file with the right creditials, doing the double open dance
> is just a waste and unnessary.  If someone is racing you, it doesn't
> matter since if you win the race, you open a file you have access to,
> if you lose, you can't.

That doesn't make any sense at all.  Not any whatsoever!   What the heck
are you getting at?

If someone is racing you and you open a file you have access rights to
open, then what, exactly, have you lost?!?!?!?!?

The implication you seem to be making here is that there's no way to
win, in which case we may as well just "chmod u+s /bin/* /usr/bin/*" and
be done with it all!

> On a political note, I suspect that there will be a lot of pressure
> for the other BSDs to pick up things like this, and I strongly suspect
> that it will be an extreme firefight to get it into FreeBSD.  It seems
> too specialized to be worth the fight.

It's only "too specialized" if the other necessary fix of disabling
saved-set-ID swapping is not also enforced.  If that fix is enforced
then it is absolutely necessary in order to avoid the acces()/open()
race!

In the end it all depends on just how eager you are to avoid what I
suspect is the primary cause of buffer overflow and printf format trust
exploits in set-ID programs -- i.e. exploits that are made possible by
saved-set-ID swapping.  The changes I've proposed will mitigate the
dangers of such exploits such that they will be nearly impossible
against any program takes even the slightest amount of care.

The fact that such changes will also make it possible to safely retain
at least the $TZ feature (of allowing specification of an arbitrary
tzfile), and maybe even $HOSTALIASES (if you don't have other worries
about name-to-location mapping security), is really only an added bonus,
not a core reason to accept such changes.

> It seems that the introduction of setr*id() has caused more problems
> than the minor compatibility that it gave with other systems. :-)

That's for sure, though I'm not so sure you meant it in the way that it
is really so!  :-)

-- 
							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>