The scheme I am proposing requires root priveleges to change any
user's uid or gid, so I'm not sure what you mean here.

The scheme prevents bugs in passwd(1) from being local root
compromises (as happened with the format string bug of SA2000-15).

In my view, the valid criticisms it has received so far are:

  1)  makes it hard to prevent determined users from choosing bad
      passwords
  2)  makes it hard to force users to change passwords periodically
  3)  makes it possible to set a user's password without knowing the
      current one (though in the current scheme you could instead
      trojan their shell init scripts)
  4)  makes it impossible to make both username->uid and uid->username
      mappings perform as well as currently (no pwd_mkdb(8))

These against the benefits of:

  1)  removal of a few setuid root programs from the default
      installation
  2)  enforcement of security-critical stuff using standard filesystem
      semantics, instead of using code in those setuid root programs

I think this is a net improvement on a workstation, where the user can
be trusted to use a decent password, and performance of user db
lookups is not critical.

Charles Blundell suggested a fun setgid scheme that addresses
criticisms 1-3 above.

Note also that one could keep the setuid scheme as an option, just not
the default one -- though of course adding complexity introduces more
opportunities for errors.  :)

  Alan

In article <Pine.NEB.4.44.0212102140260.27244-100000@server.duh.org>, Todd Vierling wrote:
> On Tue, 10 Dec 2002, Alan Post wrote:
> 
>: The current behavior *requires* either a daemon or setuid program.
> 
> What's the difference between cracking setuid in the current world and, say,
> cracking setuid apost and setting *root*'s password in the new world (and,
> since you've cracked the privs, adding the calling user to group wheel to do
> the su root)?
> 
> I'm at a loss as to what this usefully accomplishes in terms of security.
>