Bugzilla – Full Text Bug Listing
|Summary:||Apparmor dovecot profile does not match the /usr/share/doc/packages/dovecot/README.SUSE|
|Product:||[openSUSE] openSUSE Distribution||Reporter:||David Chewning <chevy.stroker>|
|Component:||AppArmor||Assignee:||Christian Boltz <suse-beta>|
|Status:||RESOLVED INVALID||QA Contact:||E-mail List <qa-bugs>|
|Priority:||P5 - None||CC:||chevy.stroker|
|Found By:||---||Services Priority:|
|Marketing QA Status:||---||IT Deployment:||---|
Description David Chewning 2018-06-30 20:40:48 UTC
The /usr/share/doc/packages/dovecot/mkcert.sh script places the created certificates in /etc/ssl/private/. Per the /usr/share/doc/packages/dovecot/README.SUSE so you don't have to read it: The script and documentation is now patched to use the following paths: /etc/ssl/private/dovecot.crt /etc/ssl/private/dovecot.pem None of the usr.lib.dovecot.* file give /etc/ssl/private/* r, to dovecot. I would recommend placing that line in /etc/apparmor.d/usr.lib.dovecot.auth or modifying the script to place the files in something like /etc/dovecot/private. The 1st solution is a quicker fix. the 2nd solution is a more secure restriction around dovecot.
Comment 1 Christian Boltz 2018-07-01 10:16:29 UTC
The dovecot profiles that need access to the certificates have #include <abstractions/ssl_keys> and that abstraction allows to read everyting in /etc/ssl/ ("/etc/ssl/** r,") so everything should work as expected. Do you have a "real" problem (breakage in dovecot or DENIED lines in /var/log/audit/audit.log), or did you only stumble over this after reading the dovecot profiles?
Comment 2 David Chewning 2018-07-01 13:44:22 UTC
I ran across this after seeing two people with issues i the opensuse forms with denied file permissions after running the script. My apologies if I am incorrect. Please give me a few hours to see if I can reproduce the dovecot error and report back. I only know I did not receive their errors when I placed my certs inside of /etc/dovecot. I am learning Apparmor and may have jumped the gun on my conclusion. I will provide you a test case where it breaks or report back if I cannot produce the case.
Comment 3 David Chewning 2018-07-01 15:25:44 UTC
OK, please remove the Apparmor part of this. If you want to close this report and have me resubmit please do. This is a dovecot issue if I understand the configuration correctly. Or I can edit the title. please advise. I will freely admit I created my own certificates for dovecot, and in the process fixed the original issue without being aware the README.SUSE was not clear/old. System: 1. Leap 42.3 KDE Desktop default install with a static IP. 2. Fully patched. 3. reboot 4. Install dovecot and let the packaging system install dependencies. 5. systemctl enable dovecot.service 6. Reboot and dovecot is happy Here is where things break and /usr/share/doc/packages/dovecot/README.SUSE seems to be incorrect. 1. Instructed to edit /usr/share/doc/packages/dovecot/dovecot-openssl.cnf - Completed. 2. Instructed to run /usr/share/doc/packages/dovecot/mkcert.sh - This is suppose to generate two files: /etc/ssl/private/dovecot.crt /etc/ssl/private/dovecot.pem Instead, only the .pem is generated which vary well could contain the certificate chain. 3. Instructed to edit /etc/dovecot/dovecot.conf and set ssl_disable = no. The actual file to edit is /etc/dovecot/conf.d/10-ssl.conf The variables to be uncomented and modified in 10-ssl.conf are: ssl = yes ssl_cert = </etc/ssl/private/dovecot.crt ssl_key = </etc/ssl/private/dovecot.key Note the last line was a .pem, but my self-signed cert/key were .crt/.key. I did not take the time to actually determine if the .pem certificate was actually a self-contained entire certificate chain. Once the documentation failed I generated the cert/key manually where I had control. So, it may very well work just uncommenting the two lines below and be secure: ssl = yes ssl_key = </etc/ssl/private/dovecot.pem The individuals complaining about a permission error seemed to be running up against an Apparrmor issue since they were placing their cert/key in /etc/postfix. On looking at Apparmor I did not find the reference to /etc/ss/private (my grep -R must have failed me). So, I created the directory /etc/dovecot/private and placed my cert/key there. How I generated the key is probably unimportant. Apologies for reporting the wrong issue, but there does appear to be a documented steps issue in /usr/share/doc/packages/dovecot/README.SUSE which maybe easier to fix.
Comment 4 Christian Boltz 2018-07-01 20:02:46 UTC
(In reply to David Chewning from comment #3) > Here is where things break and /usr/share/doc/packages/dovecot/README.SUSE > seems to be incorrect. > 1. Instructed to edit /usr/share/doc/packages/dovecot/dovecot-openssl.cnf - > Completed. Having to edit a file in /usr/ doesn't sound like the best idea ;-) When you report the other issues for README.SUSE, you should probably also add a note about this detail. > [...] > The individuals complaining about a permission error seemed to be running up > against an Apparrmor issue since they were placing their cert/key in > /etc/postfix. Right, that obviously isn't allowed in the dovecot profiles. > On looking at Apparmor I did not find the reference to /etc/ss/private (my > grep -R must have failed me). See my previous comment - the rule says /etc/ssl/**, so you won't find "private" in it. > Apologies for reporting the wrong issue, but there does appear to be a > documented steps issue in /usr/share/doc/packages/dovecot/README.SUSE which > maybe easier to fix. No worries - I prefer a superfluous bugreport over having something unnoticed. And, as a side effect, you probably learned something ;-) I'll close this bugreport - in theory, you could move it to the dovecot maintainer to get README.SUSE fixed, but opening a new bugreport (you can even do some copy&paste) makes things less confusing ;-)