Date:	Wed, 6 Jan 1999 19:27:36 -0500
From:	Illuminatus Primus <vermont@GATE.NET>
Subject:      Re: Wiping out setuid programs
To:	BUGTRAQ@NETSPACE.ORG

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.

On Wed, 6 Jan 1999, D. J. Bernstein wrote:

> 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().

Identifying a local user connected via a unix socket is something that
would come in handy for a lot of programs.  A portable library designed to
do this from a common interface would help.

Systems that don't implement something similar to getpeeruid() could be
shimmed by using a privileged daemon to drop a random key into files
readable only by the user and the program requesting authentication; the
client presents the key to the authenticating service for verification.

The attack with this method is DoS: request lots of authentication.
However, using a drop directory described in my next scheme, perhaps the
work of generating the key could be left to the client.  The
authenticating service would simply compare the socket key with the
filesystem key and reply "good" or "bad".

"Secure" Drop Directories

Wietse Venema said that daemons were not a reliable way to queue mail,
since the system may not always be in multi-user mode.  Because set[ug]id
gateways have been decided to be too pourous, and world-writeable drop
directories have other problems, I looked for a better way to (ab)use the
filesystem into providing inter-uid IPC.

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.

How would the queue daemon pick up the messages?

Obviously searching through so many directories would be a difficult (but
not impossible) task.  Thankfully, a way to "hint" to the daemon and help
it narrow it's search can be shimmed through the FS too.  At each level of
the hashed directories, a file "CHANGED" could exist.  When the last
access time of a "CHANGED" file increments, the queue daemon could recurse
into the tree, following the "CHANGED" files like breadcrumbs to the
eventual queued message.

A message dropper would simply have to read each appropriatte "CHANGED"
file to update it's access time.

A lame attacker could waste the queue daemon's time by reading many
"CHANGED" files.  Perhaps if this is seen as a damaging attack the name of
the breadcrumbs could be obscured by blocking directory read permissions
and having each path have a unique breadcrumb filename combination.

All this trouble to make a secure & robust drop directory in UNIX.

If the existent users could be polled, the trouble of creating a large
hierarchy of directories and hashing them could be avoided.  Only existent
users need have a drop directory.  Home directories you say? They might
often be remotely mounted and unavailable in single user mode. Creating a
drop directory with account creation would help avoid all this
complication.

> 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.

I hope this is a worthwhile contribution.

-vermont@gate.net