On Thu, 30 Nov 2000, Greg A. Woods wrote:

> On the other hand I've shown at least circumstantially that the
> restriction POSIX.1 puts on never allowing a privileged process to
> regain its privileges after dropping them with setuid() has a very
> positive benefit in that set-ID programs designed explicitly for POSIX.1
> are less likely to suffer from the types of exploits which allow a
> cracker to insert unauthorised code into a process since by the time
> this is likely the process will have forever given up its privileges
[...]

  This ability is just as easily available when you can switch effective
IDs.  The only difference is that if you can temporarily switch IDs you
can run less code at the higher privilege when you still need the
privileged ID later.

  It was pointed out to me in private mail that the logical end to the
isolation of privileged code is to remove setuid completely and use IPC.
This has convinced me that any major changes to improve setuid would not
be worth the effort, which could be better spent making it possible to run
a system without setuid (NetBSD certainly has made progress towards this
goal).

  If HOSTALIASES support is really desired for setuid programs, I think it
should be done by keeping track of the true real id in the kernel while
maintaining current behavior.  Instead of a O_REG_FILE open flag, use
O_TRUE_ID or such that opens as the true real id in all cases.  This would
solve the immediate problem in a more complete way than O_REG_FILE without
breaking compatibility for setre[ug]id programs.

Matthew Orgass
darkstar@pgh.net