James Moe:
Checking application/pgp-signature: FAILURE
-- Start of PGP signed section.
> postfix v3.2.0
> linux v4.4.103-36-default x86_64
>
> Whenever postfix (re-)starts, the message below is emitted.
> Jan 12 13:59:28 sma-server3 postfix/postfix-script[32024]: warning:
> group or other writable: /etc/postfix/./ssl/cacerts
> Jan 12 13:59:28 sma-server3 postfix/postfix-script[32040]: starting the
> Postfix mail system
>
> Following the various paths yields the following directory listings:
>
> $ ls -l .
> drwxr-xr-x 1 root root 24 Nov 4 13:04 ssl/
> $ ls -l ssl/
> lrwxrwxrwx 1 root root 15 Nov 4 13:04 cacerts -> ../../ssl/certs/
The above is not needed, if you configure Postfix to read the system
SSL certificate database with "tls_append_default_CA = yes". Not a
good idea if you use certificates to allow relaying!
Symlinks from /etc/postfix or other Postfix directories are not
supported, because it is hard to verify the target of a symlink and
all its parent directories are secure, at least in a shell script
that has to run on more than one OS type.
[I suppose one could add a Postfix dependency on perl and do some
more sophisticated analyses. Basically all the directories traversed
must be secure as in:
- All directories traversed while resolving a pathname under
/etc/postfix including any directories traversed while resolving a
symlink target must be writable only by root. And of course so must
be the file that we eventually arrive at.
- Similar logic for /var/lib/postfix, except that files/directories
must be writable only by postfix (Postfix never writes to such files
as root).
- The rules for /var/spool/postfix are more complex because some
directories must be writable only by root and others only by postfix.
A potential complication with symlinks is that they may create a
loop, so a Postfix checker would have to be robust against that.
If the postfix user becomes compromised, then a malicious symlink
from /var/spool/postfix should not result in damage to the host.]
Wietse
