Bug 436287

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

So it will not be so easy, the deliver utility (that can be used by MTAs for
optimized local delivery) can be run under different users. See #452088 for details.

I've requested a CVE id for this.

After doing some investigation, I don't think suggesting people use the -p option is right.  This has the potential to hang a booting system while waiting for a password, no?

Is there a reason we can't go with the file permission fix Fedora did?

The result in Fedora was that the permissions changes were reverted back to 0644. Unfortunately there is no guarantee how is the deliver utility run.

Yes, it is a trade between storing the password in world readable file and requirement of user interaction during startup.

Just so I'm understanding this correctly.  Will the bootup process hang waiting for user input if this option is used?

Also, why can't we set the configuration file to 0640 root:mail and set deliver to run sgid mail?

(In reply to comment #10)
> Just so I'm understanding this correctly.  Will the bootup process hang waiting
> for user input if this option is used?

yes

(In reply to comment #11)
> Also, why can't we set the configuration file to 0640 root:mail and set deliver
> to run sgid mail?

I think we can. I missed somehow the possibility of using sgid.

Adding new maintainer into CC.

deliver isn't really designed to be run securely as setuid/setgid. You could have worse security holes by making it a default..

For example if you make it setgid-mail, the mail group isn't dropped while deliver is being run. That in turn has all the same problems as http://dovecot.org/list/dovecot-news/2008-March/000060.html

I don't really see any simple solutions for this. Perhaps the proper fix would be to add some include-file capability for dovecot.conf, so that could include dovecot-secret.conf containing the password.

fix using setgid was reverted. New patch adds !include and !include_try directive for conf file, so password can be stored in separated root only readable file.

Release note added. If any revisions are required, please set the 
"requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

New Contents:
Users running dovecot with password protected ssl key are advised to store password in separated file included to dovecot.conf via !include_try directive. This password containing file should be owned by root with 0600 permissions.

Release note updated. If any revisions are required, please set the 
"requires_release_notes"  flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

Diffed Contents:
@@ -1 +1,9 @@
-Users running dovecot with password protected ssl key are advised to store password in separated file included to dovecot.conf via !include_try directive. This password containing file should be owned by root with 0600 permissions.+Users running dovecot with password protected ssl key are advised to store password in separated file included to dovecot.conf via !include_try directive. This password containing file should be owned by root with 0600 permissions.
+
+from bforte's errata draft for 2008/12/04: <https://errata.devel.redhat.com/errata/show/7790>
+
+A password disclosure flaw was found with Dovecot's configuration file. If a system had the "ssl_key_password" option defined, any local user could view the SSL key password. (CVE-2008-4870)
+
+Note: This flaw did not allow the attacker to acquire the contents of the SSL key. The password has no value without the key file which arbitrary users should not have read access to.
+
+To better protect even this value, however, the dovecot.conf file now supports the "!include_try" directive. The password can be placed in a file owned by, and only readable and writable by, root (ie 0600). This file can then be referenced from dovecot.conf by setting the ssl_key_password option to "!include_try [/path/to/password/file]".

Release note updated. If any revisions are required, please set the 
"requires_release_notes"  flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

Diffed Contents:
@@ -1,7 +1,3 @@
-Users running dovecot with password protected ssl key are advised to store password in separated file included to dovecot.conf via !include_try directive. This password containing file should be owned by root with 0600 permissions.
-
-from bforte's errata draft for 2008/12/04: <https://errata.devel.redhat.com/errata/show/7790>
-
 A password disclosure flaw was found with Dovecot's configuration file. If a system had the "ssl_key_password" option defined, any local user could view the SSL key password. (CVE-2008-4870)
 
 Note: This flaw did not allow the attacker to acquire the contents of the SSL key. The password has no value without the key file which arbitrary users should not have read access to.

release notes fixed because they contained wrong information

!include_try directive is used this way:

OLD way:

dovecot.conf
...
ssl_key_password=my_secret_but_readable_password
...
-------------------------------------

NEW way:

dovecot.conf
...
#ssl_key_password= don't write password here, just link file containing password
!include_try file_with_password
...


file_with_password can for example be /etc/dovecot.sslpassword

this new file_with_password is readable(and writable) only for root and it contains line:

ssl_key_password=my_secret_password

its *NOT* : ssl_key_password=!include_try file_with_password

Release note updated. If any revisions are required, please set the 
"requires_release_notes"  flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

Diffed Contents:
@@ -2,4 +2,4 @@
 
 Note: This flaw did not allow the attacker to acquire the contents of the SSL key. The password has no value without the key file which arbitrary users should not have read access to.
 
-To better protect even this value, however, the dovecot.conf file now supports the "!include_try" directive. The password can be placed in a file owned by, and only readable and writable by, root (ie 0600). This file can then be referenced from dovecot.conf by setting the ssl_key_password option to "!include_try [/path/to/password/file]".+To better protect even this value, however, the dovecot.conf file now supports the "!include_try" directive. The ssl_key_password option should be moved from dovecot.conf to new file owned by, and only readable and writable by, root (ie 0600). This file should be referenced from dovecot.conf by setting the "!include_try [/path/to/password/file]".

Release note updated. If any revisions are required, please set the 
"requires_release_notes"  flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

Diffed Contents:
@@ -2,4 +2,4 @@
 
 Note: This flaw did not allow the attacker to acquire the contents of the SSL key. The password has no value without the key file which arbitrary users should not have read access to.
 
-To better protect even this value, however, the dovecot.conf file now supports the "!include_try" directive. The ssl_key_password option should be moved from dovecot.conf to new file owned by, and only readable and writable by, root (ie 0600). This file should be referenced from dovecot.conf by setting the "!include_try [/path/to/password/file]".+To better protect even this value, however, the dovecot.conf file now supports the "!include_try" directive. The ssl_key_password option should be moved from dovecot.conf to a new file owned by, and only readable and writable by, root (ie 0600). This file should be referenced from dovecot.conf by setting the "!include_try [/path/to/password/file]" option.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2009-0205.html