Re: Best Practices for private key files handling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux