[ On Wednesday, December 11, 2002 at 15:18:43 (+0000), Alan Post wrote: ]
> Subject: Re: replacement for /etc/passwd
>
> The scheme prevents bugs in passwd(1) from being local root
> compromises (as happened with the format string bug of SA2000-15).

Bugs in programs run as root are very serious bugs regardless of whether
the program is setuid or not.  I.e. the problem here isn't necessarily
setuid -- it's the bug in the program.  Any program run by a privileged
user runs with the priviledges of the user and a bug could create a
security issue just as easily as a bug in a setuid program can allow an
unauthorized privilege escalation.  (think symlink races and other such
sillyness -- such bugs affect every program root runs, not just the
setuid ones)


> These against the benefits of:
> 
>   1)  removal of a few setuid root programs from the default
>       installation

I think you really need to re-think your basically unfounded dislike of
especially these few setuid-root programs.

One way or another there must be a means of elevating the privileges of
a process.  In essence the mechanism is irrelevant.

MULTICS had rings and gates.  UNIX has the superuser and setuid.

Also, you're attacking exactly the wrong programs if you want to reduce
the amount of code that runs set-user-id root.

User authentication and authorisation is the most critical part of how
system security works in any trusted computing system.

The requirement that the user be re-authenticated before he or she is
allowed to change his authentication key has been very important and I
for one won't be in any hurry to do away with this requirement at least
so long as the authentication mechanism I'm using is the traditional
unix multi-use password scheme.

However I don't think that's the most critical flaw in your scheme.

Worse is the fact that the stored representation of the key is now
readable by the user, and thus by anyone who can use a user's session
behind their back for a moment or two.  In other words someone who can
gain such access can steal the user's authentication token, probably
without them ever even knowing, and then crack the password offline.
That was the whole point to going to "shadow password" files in the
first place.

Also there is the problem that the file containing the key is owned by
the user and thus can have its permissions changed.  This makes it
easier for users to screw up and makes it even easier for this private
information to be accidentaly made publically available.

>   2)  enforcement of security-critical stuff using standard filesystem
>       semantics, instead of using code in those setuid root programs

Setuid _is_ a standard filesystem semantic, _especially_ set-user-id to
root where there's no sillyness of trying to prevent the user from
changing his own program.


Why not attack and fix all those other programs that never have to run
as root (at least not if they're handed sockets pre-bound to privileged
ports, etc.)?

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>