From owner-freebsd-security  Wed Jan  6 11:42:06 1999
Return-Path: <owner-freebsd-security@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id LAA26653
          for freebsd-security-outgoing; Wed, 6 Jan 1999 11:42:06 -0800 (PST)
          (envelope-from owner-freebsd-security@FreeBSD.ORG)
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16])
          by hub.freebsd.org (8.8.8/8.8.8) with SMTP id LAA26628
          for <freebsd-security@freebsd.org>; Wed, 6 Jan 1999 11:42:01 -0800 (PST)
          (envelope-from brian@hyperreal.org)
Received: (qmail 23083 invoked by uid 24); 6 Jan 1999 19:41:32 -0000
Message-Id: <4.1.19990106113411.00bdc780@hyperreal.org>
X-Sender: brian@hyperreal.org
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 06 Jan 1999 11:34:27 -0800
To: freebsd-security@FreeBSD.ORG
From: Brian Behlendorf <brian@hyperreal.org>
Subject: Fwd: Wiping out setuid programs
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-freebsd-security@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org


This seemed like a relevant post to this forum.

	Brian

>Delivered-To: brian@HYPERREAL.ORG
>Approved-By: aleph1@UNDERGROUND.ORG
>Date:	Wed, 6 Jan 1999 04:07:54 -0000
>Reply-To: "D. J. Bernstein" <djb@CR.YP.TO>
>Sender: Bugtraq List <BUGTRAQ@NETSPACE.ORG>
>From:	"D. J. Bernstein" <djb@CR.YP.TO>
>Subject:      Wiping out setuid programs
>To:	BUGTRAQ@NETSPACE.ORG
>
>This is a continuation of the ``Why you should avoid world-writable
>directories'' thread.
>
>Why do we create setuid programs? Because we need to let users access
>particular files in restricted ways. Some traditional examples:
>
>   program   files
>   -------------------------
>   at        the at queue
>   atq       the at queue
>   atrm      the at queue
>   chfn      /etc/passwd
>   chpass    /etc/passwd
>   chsh      /etc/passwd
>   crontab   the cron queue
>   cu        serial lines
>   eject     floppy disks
>   fdformat  floppy disks
>   lock      /etc/shadow
>   lpr       the print queue
>   lprm      the print queue
>   netstat   kernel memory
>   passwd    /etc/shadow
>   ps        kernel memory
>   rlogin    low TCP ports
>   rsh       low TCP ports
>   sendmail  the mail queue
>   talk      terminals
>   tip       serial lines
>   wall      terminals
>   write     terminals
>
>In every case the file access could be moved to a non-setuid daemon that
>accepts UNIX-domain connections from unprivileged user programs. This
>would wipe out a huge number of local security holes.
>
>However, in most cases, the daemon needs to know who it's talking to,
>for access control or for accounting. That's why I want a getpeeruid()
>routine returning the uid that called connect().
>
>It turns out that Linux 2.1 already supports this feature. You can
>implement getpeereuid() and getpeeregid() with a few lines on top of
>getsockopt() with SO_PEERCRED. Other systems could easily add support.
>
>A few people have commented that getpeeruid() doesn't give per-packet
>uids: if a user connects to the socket, and runs a setuid program, then
>the program's input and output will be attributed to the user. So what?
>The user could just as easily have run "cat | thesetuidprogram | cat",
>and he really does own the cat processes.
>
>Anyway, I've set up a web page discussing various IPC mechanisms from
>the writing-daemons-that-manage-restricted-files point of view:
>
>   http://pobox.com/~djb/docs/secureipc.html
>
>Please let me know if you have any updates.
>
>---Dan

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
History is made at night;                         brian@hyperreal.org
  character is what you are in the dark.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message