[ On Monday, November 20, 2000 at 09:16:05 (-0800), Greywolf wrote: ]
> Subject: Re: Addition to force open to open only regular files
>
> The whole POSIX thing about discarding the saved set uid if the user
> is super-user is nothing but a band-aid which impedes any semblance
> of flexibility with regard to switching UIDs if used as directed.
> It's a band-aid because one can simply fork, setuid(), do their thing
> and exit().

Ah, no, it's not a band-aid.  It's a historical compromise between
short-sighted programmers who think they need the ID-swapping feature
and true security under the Unix set-ID process model.  The compromise
is specifically to allow such short-sighted programmers to FSCK
non-superuser IDs while never permitting the most obvious superuser
compromises.  Indeed part of the reason for this compromise is to help
solve some of the problems identified in your point that I address last
below.

The problem with this compromise is that it still allows for the easy
creation of obvious paths to higher privileges (eg. by having a
setuid-operator program that modifies mechanisms which might permit
access to root privileges), and yet no matter how obvious the path might
be to a cracker it seems that the designers of such programs are always
completely obvlivious to them.

> That is _entirely_ beside the point.  I think it should still be
> *possible*,

I believe that open_as() is a better answer since it solves all of the
related problems that I'm aware of without needing any ID-swapping.  [If
anyone has any claims to the contrary I'd be more than willing to
contemplate them and see if they might be solved some other way.]

It still even provides enough rope that you could still be FUBARed by a
cracker finding some path to higher privilege through modification of
data that the effective-ID is permitted to modify even after you've done
a seteuid(getuid()).  [Note that setuid(getuid()) would still be
required to overwrite the saved-set-IDs with the real-IDs thus
permanently preventing even open_as() from getting out-of-hand.]

> and I agree neither with the proposal of discarding setuid()
> on a fork() by dictation, nor with the other proposal of resetting the uid
> after every system call.

I'm still thinking of the practicality of forcing setuid(getuid()) in
fork() [and I may even, in my (not)copious spare time, build a system
with this wrapper to see what breaks].

You can be pretty sure that I too consider the idea of forcing
seteuid(geteuid()) before system calls that need it (and resetting the
effective-ID to be the real-ID after every such call) to be mostly pure
fancy though -- that's a major paradigm shift in setuid and would be
unlikely to ever be practical.  I pointed it out just as an illustration
of ways that set-ID programmers might be made more aware of the
environment they are working in (it doesn't really provide any real
protection -- just the illusion of it).

>  I still maintain it would be a nightmare, as
> setuid() programs would not be able to use standard libraries (unless they
> were rewritten in a major way, which would be a total paradigm redesign
> on one of the lesser fundaments of the OS, if not the *NIX concept).

Note that all of the SysV world required avoiding seteuid() for the
longest time anyway, so there's really not a lot of code to rewrite if
you remove ID-swapping.  I.e. there's no major paradigm shift here --
you just get rid of a relatively new feature that should never have been
introduced in the first place.

> I will note, by the way, that if the real UID is 0 while the effective
> one is not, you can get some strange things happening, for what it's
> worth...I forget what they are ("Aw, he's just blowing smoke again!"
> No, really!...), but I've seen them happen; permissions somehow denied
> for one vnop while being granted for another; I think it was chown()
> vs. chmod(), or maybe it was the ability to kill a process vs. a vnop.

You're absolutely right.  Set-ID programs that are not set-UID-root need
to take great care not to do things that they might not normally be
permitted to do had they been invoked by an ordinary user (IIRC this is
also one of the top-ten rules of set-ID programming).

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