Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#43059 - [openssl] /etc/ssl/private has far too permissive permissions by default

Attached to Project: Arch Linux
Opened by Patrick Goetz (pgoetz) - Tuesday, 09 December 2014, 22:01 GMT
Last edited by Evangelos Foutras (foutrelis) - Tuesday, 12 April 2022, 04:11 GMT
Task Type Bug Report
Category Security
Status Assigned
Assigned To Pierre Schmitz (Pierre)
Felix Yan (felixonmars)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 9
Private No

Details

Package: openssl 1.0.1.j-1

Description: The permissions on /etc/ssl/private are far too permissive by default:

# cd /etc/ssl
# ls -l private
drwxr-xr-x 2 root root 4096 Sep 9 05:34 private

This allows anyone with a login to get into the private key folder. If someone messes up the permissions on a key file, the key becomes publicly accessible.

Suggestion: the debian configuration for this is pretty good. First, create an ssl-cert group:

# grep ssl-cert /etc/group
ssl-cert:x:113:postfix,cyrus

Then set the permissions on /etc/ssl/private accordingly:

# cd /etc/ssl
# ls -ld private
drwx--x--- 2 root ssl-cert 4096 Sep 9 05:34 private

As illustrated above, services which need access to the private key store can then be added to the ssl-cert group. Of course the keys will also need to be owned by ssl-cert and group readable.

This task depends upon

Comment by Allan McRae (Allan) - Tuesday, 09 December 2014, 23:03 GMT
It is only read permission for non-root. How are they going to mess up the keys?
Comment by Patrick Goetz (pgoetz) - Tuesday, 09 December 2014, 23:21 GMT
They can't mess up keys, but can obtain copies. These are supposed to be the *private* keys that no one sees.
Comment by Patrick Goetz (pgoetz) - Wednesday, 10 December 2014, 16:03 GMT
I just realized the confusion caused by my initial posting (which I can't edit). What I meant was if a system administrator creating a public-private key pair inadvertently makes the key file publicly readable, anyone with a login can harvest it from the private key folder under current conditions. This is most definitely undesirable. I'm not sure what the security concerns are regarding having ordinary users know what the set of private keys is, but this could also be a problem. Usually when it comes to cryptographic considerations, you can't be too paranoid.
Comment by Patrick Goetz (pgoetz) - Saturday, 10 January 2015, 10:09 GMT
I just got an openssl update (1.0.1.k-1) which informed me that

warning: directory permissions differ on /etc/ssl/private/
filesystem: 710 package: 755
warning: directory ownership differs on /etc/ssl/private/
filesystem: 0:113 package: 0:0

indicating that this issue hasn't been addressed yet. This is I think a very serious security issue with a very simple solution. What's the holdup in getting this addressed?
Comment by Pascal Ernster (hardfalcon) - Friday, 10 June 2016, 16:30 GMT
/etc/ssl/private should either have chmod 700, or be eliminated altogether (I'd favor the second option).

Patrick: If you are storing private keys for different users in the same directory, chances are high that your configuration is broken anyhow. The very concept of storing the private X.509 keys for different daemons/users in a single common directory seems terribly misguided (at least to me).
Comment by Levente Polyak (anthraxx) - Monday, 02 January 2017, 19:39 GMT
what is holding up this ticket, can we get some progress? its not really rocket science :P
I think the approach debian choose with a ssl-cert group and according dir permissions for /etc/ssl/private are the way to go.
Comment by A R (a2n) - Friday, 10 April 2020, 08:28 GMT
Hello, is there anything new about this issue?

Loading...