Best Practices for private key files handling

[Philip Prindeville]

> On Sep 13, 2022, at 8:10 PM, Shawn Heisey via openssl-users <openssl-users at openssl.org> wrote:
> 
> 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
> 


I was thinking of the case where the directory containing the keys (as configured) is correctly owned, but contains a symlink pointing outside of that directory somewhere else... say to a file owned by an ordinary user.

In that case, as has been pointed out, it might be sufficient to just pay attention to the owner/group/modes of the file and reject them if:

(1) the file isn't 600 or 400;
(2) the file isn't owned by root or the app-id that the app runs at.

Do we agree on that?

-Philip