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