From owner-freebsd-hackers  Tue Jun 17 23:23:25 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id XAA00923
          for hackers-outgoing; Tue, 17 Jun 1997 23:23:25 -0700 (PDT)
Received: from polya.blah.org (slmel12p01.ozemail.com.au [203.108.200.89])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA00913
          for <hackers@FreeBSD.ORG>; Tue, 17 Jun 1997 23:23:19 -0700 (PDT)
Received: (from ada@localhost)
          by polya.blah.org (8.8.5/8.8.5) id QAA03038
          for hackers@FreeBSD.ORG; Wed, 18 Jun 1997 16:23:11 +1000 (EST)
From: Ada T Lim <ada@not-enough.bandwidth.org>
Message-Id: <199706180623.QAA03038@polya.blah.org>
Subject: Re: hackers-digest V3 #242
In-Reply-To: <199706172053.NAA06861@hub.freebsd.org> from "owner-hackers-digest@FreeBSD.ORG" at "Jun 17, 97 01:53:07 pm"
To: hackers@FreeBSD.ORG
Date: Wed, 18 Jun 1997 16:23:10 +1000 (EST)
X-Mailer: ELM [version 2.4ME+ PL32 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> > This in turn requires the kernel have the mechanism to access the
> > credential store, which may equate to bundling every possible password
> > access mechanism with the kernel; yeah, let's suck in all the Kerberos
> > stuff, NIS, Radius, S/Key, ssh, Tacacs, SecurID, the Captain Midnight
> > Secret Decoder Wheel algorithm, and so on.
no it doesnt;  all it needs is a reworked setuid() -
setuid(id) {
if(id !=0 && getuid()==trusteduser) uid = id;
etc.  (I know this isn't right, but hopefully you get the idea.)

> > You'll note that there's no actual attempt to justify why
> > authentication by root and subsequent sacrifice of priveledge is
> > actually _bad_.
Oh, why don't you make _every_ one of your programs setuid, and then put
in a seteuid() call somewhere?  because holes exist.

> > Alternatively, consider using the PAM framework, which is compact,
> > open to analysis, and once analysed, every program that uses it is
> > much simpler to analyse in itself.  If PAM interests you, see the
> > references off my homepage (http://www.smith.net.au/~mike).
> 
> As shared library(s), it still appears to encourage granting root to a
> program as trivial a POP3 server which only needs normal user access.
> This temporary root access is, to me, inherently more dangerous than
> taking a program from no access to the specific user id without a stop
> at the higher priv level.

I've already been flamed by deraadt for this, so I _know_ I'm onto a good thing
:)

Anyhow, what would be a good way to implement 'setuid libraries'?  (The idea
being that all function calls to this library have an implicit setuid(0) first
and a setuid() back afterwards.

This would mean that things like ptyopen() etc could be used in user-programs
without needing to be root.

Ada