[8991] in bugtraq
Re: Wiping out setuid programs
daemon@ATHENA.MIT.EDU (Steve Bellovin)
Fri Jan 8 13:35:48 1999
Date: Thu, 7 Jan 1999 15:52:07 -0500
Reply-To: Steve Bellovin <smb@RESEARCH.ATT.COM>
From: Steve Bellovin <smb@RESEARCH.ATT.COM>
X-To: Illuminatus Primus <vermont@GATE.NET>
To: BUGTRAQ@NETSPACE.ORG
In message <Pine.LNX.4.05.9901061822490.7626-100000@oto.gate.net>, Illuminatus
Primus writes:
> Wietse Venema asked me what my ideas were for inter-privilege
> communication. These are the ideas I sent to him. I'm sending it to
> Bugtraq also so that, if approved, any unnoticed holes could be pointed
> out to me.
>
>
> "Secure" Drop Directories
>
> Here it is:
> A pre-generated set of directories, each individually owned by 0-max of
> uid_t. They are only readable by the owning uid and the service the files
> are being sent to (via group ownership). To prevent the OS from thrashing
> when it tries to index the directories, they should be hashed. When a
> user wishes to drop a file into the queue, he simply writes it to his
> directory in the tree.
The problem is maintenance of that set of directories. In principle,
it may work; in practice, I fear for it.
There's a similar method that I and at least one other person has suggested
privately to Wietse: a "lock" directory. (Disclaimer: this idea isn't
mine; I first saw it in MMDF very many years ago, when the world was
young and the net was flat.)
The idea still uses setuid, but just briefly. The program does a
chdir *through* a mode 700 "lock" directory, and into a mode 777 spool
directory. The program then sheds all privileges, as irrevocably as
possible.
Since the spool directory is 777, any uid can write to it. And user
and group identification are retained. But non-privileged programs
can't get to it, because of the protected lock directory.
Is this a general solution? No, of course not. But it does work well
for things like mailers.
