Best Practices for private key files handling
openssl at elyograg.org
Wed Sep 14 02:10:22 UTC 2022
On 9/13/22 14:17, Philip Prindeville wrote:
> But what happens when the file we encounter is a symlink? If the symlink is owned by root but the target isn't, or the target permissions aren't 0600 0r 0400... Or the target is a symlink, or there's a symlink somewhere in the target path, etc.
> So... what's the Best Practices list for handling private key materials? Has anyone fleshed this out?
This is not really related to openssl, but I will tell you what you are
likely to hear in another setting:
In most cases, applications are not really aware of symlinks, unless
they have been explicitly written to treat them differently than regular
files or directories. Some software can choose to not follow symlinks,
but usually when that is possible, the program has a configuration
option to enable/disable that functionality.
All symlinks I have ever seen on POSIX systems have 777 permissions, and
MOST of the symlinks I have seen have root:root ownership. I've never
seen a situation where the ownership of the link itself has any bearing
on whether the target location can be accessed. I'm not going to
unilaterally claim that isn't possible, but I have never seen it.
Best practices do not change when there are symlinks involved, unless
the software refuses to follow symlinks. Anything that would apply to a
real file/directory would apply to the target of a symlink. My own best
practices about private keys: They should only be readable by root and
whatever user/group is active when software needs to use them. They
should definitely not be writable by any user other than root. Some
software starts as root to handle security stuff, then throws away the
elevated permissions and runs as an unprivileged user. Apache httpd is
a prime example of this.
You might be concerned that with 777 permissions, a symlink can be
modified by anyone ... but I am about 98 percent sure that is not the
case when proper permissions are used. I believe that a symlink can
only be modified by a user that has write permission to the directory
containing the symlink.
Properly implemented, symlinks do not reduce security, but any tool can
be misused. If you have a situation where a symlink presents a security
concern, it probably means someone did it wrong.
More information about the openssl-users