Key file permissions

From: Murray S. Kucherawy <msk_at_blackops.org>
Date: Thu, 22 Jul 2010 00:53:15 -0700 (PDT)

Based on some recent list chatter about key file permissions, I've added a
tentative feature to v2.2.0 that will refuse to use a key that has any of
the group/other read/write bits set. The test can be weakened via a
configuration file item to just emit a warning, but it will always do at
least that.

This seems like a good first guess, but it occurs to me that there are
some cases it would disallow that are otherwise legitimate, such as:

- root owns the keys, the keys are group-readable, but they're in a group
that only the opendkim owner is in (detecting this requires trolling the
entire password and group files looking for other members of the group)

- the keys are group/other read/writeable, but they're in a directory only
the opendkim user can access or modify (determining this requires checking
the modes on all directories from the parent to the filesystem root,
which is a lot of I/O per key access and is also not atomic)

Sendmail has a function called safefile() that is pretty thorough about
this sort of thing, but I don't want to create a library dependency just
for this, nor do I want to add any more source directly into our code
that's under someone else's license.

Maybe the check should be to refuse if:
- other read/write is set, OR
- group read/write is set and the group is something other than one of the
groups of the current process

Or we could punt completely, drop the feature, and silently leave key
security up to the system administrators.

Does anyone have any suggestions here? Is this simple test sufficient for
most cases? What would work for you? What do other projects do?

Thanks,
-MSK
Received on Thu Jul 22 2010 - 07:53:33 PST

This archive was generated by hypermail 2.3.0 : Mon Oct 29 2012 - 23:32:53 PST