Re: Someone help me understand this...?

On Thu, Aug 28, 2003 at 11:34:09AM -0400, Robert Watson wrote:
> > > Clearly, unbreaking applications like Diablo by default is desirable.  At
> > > least OpenBSD has similar protections to these turned on by default, and
> > > possibly other systems as well.  As 5.x sees more broad use, we may well
> > > bump into other cases where applications have similar behavior: they rely
> > > on no special protections once they've given up privilege.  I wonder if
> > > Diablo can run unmodified on OpenBSD; it could be they don't include
> > > SIGALRM on the list of "protect against" signals, or it could be that they
> > > modify Diablo for their environment to use an alternative signaling
> > > mechanism.  Another alternative to this patch would simply be to add
> > > SIGARLM to the list of acceptable signals to deliver in the
> > > privilege-change case.

OpenBSD does not consider a process 'tainted' if it changes credentials
while running. From the issetugid(2) manpage:

The status of issetugid() is only affected by execve().

> In most cases, fail-stop is a reasonable behavior for unexpected security
> behavior from the system, but ignore is likely to shoot you later. :-)  I
> tend to wrap even kill() calls as uid 0 in an assertion check, just to be
> on the safe side.  If nothing else, it helps detect the case where the
> other process has died, and you're using a stale pid.  It's particular
> useful if the other process has died, the pid has been reused, and it's
> now owned by another user, which is a real-world case where kill() as a
> non-0 uid can fail even when you're sure it can't :-). 

This can be avoided by careful programming: do not use SA_NOCLDWAIT and
don't pass pids to kill() when they have been returned by wait() or
similar functions. If the process has terminated in between, it's a
zombie. In that case, FreeBSD probably returns ESRCH but SUSv3 mandates
returning success (but performing no action).

Jilles Tjoelker