Best Practices for private key files handling

[Shawn Heisey]

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.

Thanks,
Shawn