It seems to me that using an "admin" token to deliver mail is
likely to have various windows of opportunity for an unscrupulous
user to break things. Owen describes a procedure that involves
making various kinds of sanity checks, making a lock file,
writine to the mailbox, then closing the mailbox -- the obvious
thing for a bad guy to do would be to arrange to lock the file,
ask the mailer to deliver something to himself, wait until
the server blocks on the lock (he's could make a timing study to
predict when this will happen, or he could use "cmdebug" to watch
for this), point his mailbox someplace else, unlock it, and lo &
behold - he can now do all kinds of interesting damage as admin.
Obviously, the checks could be done both before & after
the lock, but the essential problem remains: the operations
are not atomic, and there are still crevices for the bad
guy to sneak in (somewhat like the famous "passwdrace" program
that is so often spotted in sun machine environments.)
Rather than doing that, I think a better way might be to take
advantage of the keyfile trick [EMAIL PROTECTED]
just described - when he described klog-localauth. The trick is that,
if you know the key of AFS, you can *easily* generate a ticket
for any user on the system, and every AFS file server will believe
that ticket, no questions asked.
Here's what you'd do. You'd have a daemon running on the database
servers that would be willing to "forge" a ticket for any
user, using the keyfile on the server. That's obviously a
security weakness, so you'd want to be *VERY* sure the
server will only deliver the forged tickets to your trusted and
secure client machine, and even then only encrypted with something
only the that secure client machine might be expected to know.
On your secure client, you'd want to be *VERY* careful about just how
you'd set things up. For instance, you might have:
on the secure client:
a srvtab with the admin key, permitted ONLY to root.
file permissions should be carefully studied,
to be sure that a USER running on the secure client
can't do anything. (If you do the "chroot"
described below, this is less important.)
A server on the secure client that would run as root, and operate as
follows:
when there is mail to deliver to a user,
chdir someplace like /tmp, so a core dump is not a security problem.
as root, fetch the server key.
get a new pag.
use "setuid" to become the person.
request a forged ticket from the database server as the user,
using the server key to authenticate the request.
decrypt the request. destroy the in-core copy of the
admin key, and any session keys, tickets, or other
"privileged" information that might be a problem.
set the user's token in the kernel.
destroy any temporary copies of the user's token that
might have been made.
At this point, the process on the secure client is effectively running with
the user permissions, through & through. It can now read and write
files without worrying about symlinks, permissions, or anything
else. If the user points his mailbox to somebody else's,
it just won't work. If the user points his mailbox to /etc/passwd,
it will won't work (*ASSUMING* the secure client is properly
setup!!!) Even a core dump of the client process might
be safe to risk, although I'd still be a bit paranoid about that.
To be even a bit more thorough, it might be reasonable for the
process to do a "chroot" to the user's home directory. That would
do an even better job of ensuring that there's nothing the user
could do to trick the server into delivering stuff anywhere
else. It may also create portability problems, particularly
with solaris (and SGI?) -- things like dns name lookups &
socket calls may not work as expected if "/dev" doesn't exist.
That's probably not a problem if you're just delivering mail.
You'd need to be SURE you knew what you were doing, in order
to be sure this code is secure - but I think it's likely to be
a lot more secure than delivering mail using an admin token.
-Marcus Watts
UM ITD RS Umich Systems Group
