Re: setuid vs. setgid (was Re: Anonymous Qmail Denial of Service)

[shadows () WHITEFANG COM (Thamer Al-Herbish)]

On Fri, 8 Jan 1999, Nick Maclaren wrote:

> Consider things like job schedulers, printing systems and so on.  User
> A calls one of those, which runs as user B.  It then calls mail - the
> examples were chosen because both of them do precisely that.  Which
> is the user identification that the mailer should use?

Job schedulers == cron? It runs as you anyway. So getuid() works
fine. getlogin won't though, unless cron does a setlogin().

It is times like these that I truly wish UNIX had something remotely
similar to Capability Systems.

[ Snip: Possible solutions pretty much involve trusting user B, or
  getting him to do a little work. Neither are suitable. ]

> > When all email is cryptographically signed (and signitures enforced)
> > with keys that are not trivial to guess and aren't easily forged, then
> > we will have a better chance of being assured of a "user's identity".
>
> Over my dead body.  In the UK, the government insists on choosing the
> "trusted third parties" to hold copies of the private keys :-(

Persistant authentication is called for. A non-crypto ticket
perhaps? My understanding is, that if you don't have the whole
notion of "keys" the goverment won't mind.

Use a cookie. Are cookies allowed?

The mailer keeps a number of secrets.  Each secret could be as big
as a 512-bit number. Every user has a queue of secrets -- so if you
have 100 users, you would have 100 files with a list of secrets.

The user runs "mail-secret" gets a secret that is good for 30 days.
He hashes his username with the secret, and attaches it with his
username to the message. Note: no public/private key -- it's just a
secret. (shhh be vewy vewy quiet)

He hands the message to user B, who does not need to be concerned
about any secret type business. User B does his thing and hopefully
calls the mailer with the message in 30 days. If not he gets a big
fat error with "too late -- expired secret."

The mailer tries to hash up the same username with its 30 keys. If it
finds a match, it delivers the message under user A's name.

No public keys, no secret keys -- well just one secret.

> Be that as it may, even perfectly secure signatures don't solve the
> problem completely, either, because the intermediate agent can easily
> use one user's signature and identification for another's request.

The only way to solve this is to have each secret expire after a
single use. This throws a cork screw into my not-so-original plan,
but you can work around this if you added ID numbers to each
message. Something else you could put in an auxiliary header. Each
secret is hashed with the name, an ID number that the user passes to
user B. ID numbers are unique, of course, to each message. You can't
reuse ID numbers. This effectively makes it a one shot ticket.

Granted that this is ugly, it does allow you to proxy messages
through a middle man -- as long as you can specify headers.

--
Thamer Al-Herbish                     PGP public key:
shadows () whitefang com                 http://www.whitefang.com/pgpkey.txt
[ Maintainer of the Raw IP Networking FAQ http://www.whitefang.com/rin/ ]