[8970] in bugtraq

home help back first fref pref prev next nref lref last post

Re: Wiping out setuid programs

daemon@ATHENA.MIT.EDU (Darren Reed)
Thu Jan 7 12:15:45 1999

Date: 	Thu, 7 Jan 1999 07:22:48 +1100
Reply-To: Darren Reed <avalon@COOMBS.ANU.EDU.AU>
From: Darren Reed <avalon@COOMBS.ANU.EDU.AU>
X-To:         djb@CR.YP.TO
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To:  <19990106040754.18811.qmail@cr.yp.to> from "D. J. Bernstein" at
              Jan 6, 99 04:07:54 am

In some mail from D. J. Bernstein, sie said:
>
> 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:
[...]
> 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().
[...]
> 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.

Some of the free unix teams already have designs on how to remove setuid
and setgid from executables using `this' feature.

As with all work done in this community, progress is regulated by people's
available time and other projects in progress - which I'm sure you can
understand.  Given that it originated in the commercial sector (BSDI) (I
believe), it is reasonable to suspeect they've made some progress on this
front also.

Darren

home help back first fref pref prev next nref lref last post