[ On Thursday, November 30, 2000 at 11:19:11 (-0800), Greywolf wrote: ]
> Subject: Re: Addition to force open to open only regular files
>
> Tangentially, I can't think of anything which has mangled *BSD worse
> than POSIX.  There are quite a few things that BSD handled more gracefully
> than POSIX dictated, yet to deviate from POSIX is considered a Bad Thing
> in this world of *NIX, so BSD lost out.

That might be true, except it's not true in at least the set-ID part of
the spec.  Any widly required or accepted standard can have the effect
of stagnating innovation in the particular field where it is set (which
of course doesn't mean that POSIX stagnates all of computing -- just
that it limits the effectiveness of developing innovative new OS APIs).

So, for this specific part of the spec. we need to understand that In
POSIX.1 the only privileged user is the superuser -- other set-ID
programs are, by definition, still "unprivileged".

All POSIX "missed out on" was the ability for an unprivileged set-ID
process (i.e. one started from a setuid-non-root program) to permanently
drop its effective-ID, and in the restricted view of an OS that has only
one truly privileged user, that's not really an issue because, like I
said,

> # The fact that a setuid-non-root process can forever give up its
> # privileges makes little, or no, difference in the end.

I.e. this inability of POSIX.1 does not directly put the superuser at
risk.

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 and
thus the exploit will be much less powerful and perhaps even pointless
since no immediate privileges can be gained through it.  (It may be
possible that the non-privileged program still holds a protected file
open, or something else similarly dangerous, of course.)

The inability of unprivileged set-ID processes to permanently drop their
privileges does of course require that filesystem permissions must never
be set such that an unprivileged user process can in any way ever
influence the correct and safe operation of processes with superuser
privileges.

I.e. in general no file which the superuser will trust can ever be
allowed to be owned or writable by anyone other than just the superuser.

How far you take this depends on your specific local requirements.  If
you don't mind that an ordinary user can dial out on a modem, or print
arbitrary things (possibly denying other users the ability to print),
etc. then subsystems which control modems and printers can be set-ID to
some user or group other than 0.

A highly secure Unix-like OS should probably never start out with any
set-GID programs and never have any set-UID program that are not owned
by root, *AND* all such programs should be written to expect this
scenario and tested to ensure that they are not vulnerable.  The
managers of such an OS could then delegate trust for some specific
functions and sub-systems by *removing* privileges and creating user-IDs
which would take over responsibility for such functions and sub-systems.
Safe recipies could be written which would allow the managers of such
systems to make such changes to to systems which would be capable of
safely allowing such delegated responsibilities.  The delegation of such
responsibilities would allow such managers to safely share the workload
of operating a system without the need to provide superuser access for
functions which would be considered less risky in specific system
instances.  Adding third-party software that makes any use of any set-ID
mechanism would of course be out of the question on such a system.

There's always a toss-up between delegating such responsibilities in the
initial system implementation and requiring that managers choose which
responsibilities to delegate in specific instances.  Whether or not the
"security" gained by forcing a single system manager to wear different
hats for different functions depends on what kinds of errors such a
person is likely to make when managing various sub-systems, and of
course on whether or not it's easy enough for that person to restrict
his or her capabilities based on the task to be performed.  If you
always 'su uucp' or 'login uucp' before killing a stuck uucico process
then you win, otherwise you might accidentally kill some unrelated
process.  However if the manager with the superuser password never kills
uucp processes, but rather delegates that job entirely to the person(s)
with the uucp password, then he or she also wins (but perhaps at the
expense of having a timely response to such problems).

Adding non-Unix-like capabilities such as would be necessary to
implement a system capable of being certified as, for example, DoD B
class secure, changes this scenario greatly of course, but at the added
expense of far more complication and thus inherent risk from that added
complication.

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