[ On Tuesday, November 14, 2000 at 10:41:05 (+1100), matthew green wrote: ]
> Subject: re: Addition to force open to open only regular files 
>
> netbsd does not support _POSIX_SAVED_IDS.

Indeed.

> from <sys/unistd.h>:

This comment has always angered me.  It indicates a fundamental
misunderstanding of the core unix security model.

> /*
>  * According to POSIX 1003.1:
>  * "The saved set-user-ID capability allows a program to regain the
>  * effective user ID established at the last exec call."
>  * However, the setuid/setgid function as specified by POSIX 1003.1 does
>  * not allow changing the effective ID from the super-user without also
>  * changed the saved ID, so it is impossible to get super-user privileges
>  * back later.  Instead we provide this feature independent of the current
>  * effective ID through the seteuid/setegid function.  

This is a good thing.  Allowing a process that has run as an ordinary
user to (re)gain superuser privileges is extremely dangerous and opens
the system to many different kinds of possible vulnerabilities.  There
have been several exploits available in the past to systems which have
made this mistake and I have no doubt that there will be more in the
future.  (Solaris-2.3 and its related bretheren are one example)

While it is true that careful and complete control of all aspects of
process control in an entire system can circumvent such vulnerabilities,
the the fundamental problem with allowing an unprivileged process to
(re)gain superuser privileges is that it breaks the unix security model
and screws up peoples perceptions and understandings of how privileged
processes are created and protected.  This leads to system designers
introducing new features which do not take the appropriate precautions
and can thus be used in conjunction with sete*id() to compromise the
system.  As I say, this has happened several times in the past and it
will undoubtably happen again in the future.  The correct fix is to obey
the POSIX rules (and thus the fundamental Unix security model) and never
allow a process to (re)gain superuser privileges after it has run as an
ordinary user.

>  In addition, we do
>  * not use the saved ID as specified by POSIX 1003.1 in setuid/setgid,
>  * because this would make it impossible for a set-user-ID executable
>  * owned by a user other than the super-user to permanently revoke its
>  * extra privileges.
>  */

This is true, but it is not necessarily bad either.

In the unix security model there is really only one privileged user.
Consfuing a set-id process that is set-id to another ordinary user with
one that is set-id to the superuser by calling it "privileged" is not
correct and can be misleading.

While certain restricted privileges can be delegated to ordinary users
(eg. the right to read a raw disk by the "operator" group) can make
system management easier it is critical that system designers take
extreme care to ensure that such delegations do not introduce back doors
that allow users of the delegated privileges to go back up the chain and
compromise superuser privileges (eg. providing set-group-id "operator"
programs that can be tricked into revealing the raw disk contents to
users who are not direct members of the "operator" group).

In other words designers intending to use Unix set-ID features to
provide controlled access to privileged services and resources must
continue to take great care in how they use set-ID.  If a programmer
finds himself or herself in the position of wanting to permanently
revoke non-superuser privileges after making use of them then they
should perhaps reconsider their design such that the privileged code is
in a separate process that performs only the one task of making use of
its privileges.

As I understand it so far, the design of the BSD/OS authentication
system is an excellent example of how to cascade privileges by using
set-ID programs and filesystem controls in such a way that the most
privileged process contains the least amount of code.  If more
subsystems were designed in this manner there would be less likelihood
of attacks against the most privileged code being successful.

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