RE: key data is not secure

From: Murray S. Kucherawy <msk_at_blackops.org>
Date: Mon, 10 Jan 2011 22:37:39 -0800 (PST)

On Mon, 10 Jan 2011, Steve Jenkins wrote:
> 1) The owner and group of the keyfiles should be
> opendkim-milt.opendkim-milt, and you have "opendkim.opendkim" Make sure
> the user and group names are consistent across the entire install.
>
> 2) I also notice from your ls that your default keyfile is world and
> group readable. The tutorial states that it should have only user rw
> permissions (chmod 600).
>
> I can't guarantee those will fix it, but try those two modifications and
> let us know if you get different results.

That's pretty much dead-on. The filter considers the private key to be
insecure and thus unusable if any of the following are true:

- it's readable by the world (meaning anyone on the system can generate
signatures or steal the key)

- it's writable by the world (meaning anyone on the system can change the
key)

- it's readable or writable by the group (same reasons) and the group it's
in is not a group of which the process running the filter is a member

The tests should actually be made more comprehensive, i.e. check all
directories up the chain and make sure the only user that can read/write
the keys is the filter (or the superuser).

If you're satisfied with your system the way it is and want to bypass this
check, you can set RequireSafeKeys to "False" in your configuration file.
That won't make the error go away in your logs, but it won't prevent the
filter from operating.

-MSK
Received on Tue Jan 11 2011 - 06:38:06 PST