Certificate permissions

[arodier]

Work in progress, certificate permissions are broken again, I need to understand the ACL mask. This new approach is cleaner, and simpler, but the ACL masks seem obtrusive in the permissions. If this is too complex, then I will just cancel this and rely on AppArmor, although this is only one tool instead of two. In the second phase, I may make a difference between keys and certs.

[fredericmoulins]

I don't understand what was broken, but this last commit looks good to me: seems to handle the ACLs correctly, and avoids calling chmod two times with different rights on the certificates directories.

Step 2 is excluding the keys files from the last task?

[arodier]

Thanks, Frédéric,

I was surprised to see "effective" ACLS in the console, after a new deployment.

# file: autodiscover.hmbx.pw/
# owner: root
# group: root
user::rwx
user:www-data:r-x               #effective:---
group::r-x                      #effective:---
mask::---
other::---
default:user::rwx
default:user:www-data:r-x
default:group::r-x
default:mask::r-x
default:other::---

It seems to happen on a totally new deployment. I read carefully the ACL documentation, and the mask is prevalent.

To answer your question, yes, there is no reason, for instance, to let dovecot access openldap ssl private key. I will implement this after.

[fredericmoulins]

I was surprised to see "effective" ACLS in the console, after a new deployment.

Ok, yesterday, while testing and reading about the ACL mask calculations, I noticed the chmod commands to 0700 reset the ACL mask and restrict any ACLs already in place with #effective:---. If the mask is set afterwards, or an ACL with the mask recalculated (should be the default behavior), then it is ok. But if the chmod is executed last, the mask restricts the user ACLs.

The chmod 0700 is also set in the certificate role on the certificate directories. The order in which certificate and cert-perms are executed might give that behavior.

I don't see any call like that outside of certificate and cert-perms, except: in system-prepare, the archive and live directories are created with 0750; in the nginx tasks, an acl call is still there for the archive and live directories. Even if these two might be superfluous now, I don't see how they can cause an issue.

About the certificates and private keys, the server processes users (www-data for nginx, dovecot, postfix, etc) might not need access to the private key if it is read by the "master" process run as root. It seems to be the case for nginx (to be tested). I believe it is also the case for postfix (not sure).

[arodier]

Thank you, your explanations are very logic. For private key access, I might not be so granular at the beginning. It is more preventing, for instance, nginx, to access openldap private keys.

[arodier]

This is almost ready for review.

Certificate directory permissions:

drwxr-xr-x+ 2 root root 4.0K Dec 14 08:45 autoconfig.hmbx.pw
drwxr-xr-x+ 2 root root 4.0K Dec 14 08:44 autodiscover.hmbx.pw
drwxr-xr-x+ 2 root root 4.0K Dec 14 09:20 hmbx.pw
drwxr-xr-x+ 2 root root 4.0K Dec 14 08:33 imap.hmbx.pw
drwxr-xr-x+ 2 root root 4.0K Dec 14 07:35 ldap.hmbx.pw
drwxr-xr-x+ 2 root root 4.0K Dec 14 08:32 mta-sts.hmbx.pw
drwxr-xr-x+ 2 root root 4.0K Dec 14 08:21 smtp.hmbx.pw
drwxr-xr-x+ 2 root root 4.0K Dec 14 08:40 sogo.hmbx.pw
drwxr-xr-x+ 2 root root 4.0K Dec 14 08:38 webmail.hmbx.pw
drwxr-xr-x+ 2 root root 4.0K Dec 14 08:42 www.hmbx.pw

One certificate permissions:

root@hmbx:/etc/letsencrypt/archive/ldap.hmbx.pw# ll
total 16K
-rw-r-----+ 1 root root 1.9K Dec 14 07:35 cert1.pem
-rw-r-----+ 1 root root 1.7K Dec 14 07:35 chain1.pem
-rw-r-----+ 1 root root 3.5K Dec 14 07:35 fullchain1.pem
-rw-r-----+ 1 root root 1.7K Dec 14 07:35 privkey1.pem
root@hmbx:/etc/letsencrypt/archive/ldap.hmbx.pw# getfacl cert1.pem 
# file: cert1.pem
# owner: root
# group: root
user::rw-
user:openldap:r--
user:dovecot:r--
group::---
mask::r--
other::---

All the tests are passing.

The cert-perms role is hugely commented, what is done, why and in which order, especially the acl/mask behaviour. About the user www-data, I am not sure if it should be granted access to private keys. I am doing some tests now, to see if this is necessary.

[arodier]

I forgot to mention, this is working both on a fresh install, and when reusing previous certificates, on deployment.

[arodier]

I have removed all nginx set permission calls, this is working well. Dovecot can only read ldap certs, not private keys. Works well too.