> On Sep 15, 2022, at 4:27 PM, Michael Wojcik via openssl-users <openssl-users@xxxxxxxxxxx> wrote: > >> From: openssl-users <openssl-users-bounces@xxxxxxxxxxx> On Behalf Of Philip >> Prindeville >> Sent: Thursday, 15 September, 2022 15:41 > >> 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. > > #2 is irrelevant if #1 holds and the application isn't running as root. And if the application doesn't need to run with elevated privileges, it shouldn't be run with elevated privileges. > > You still haven't explained your threat model, or what mitigation the application can take if this requirement is violated, or why you think this is a "best practice". > > It's true there's potentially some benefit to warning an administrator even after the fact if some violation of key hygiene is detected, but whether that's a "best practice" (and, for that matter, the extent to which file permissions constitute evidence of such a violation), much less whether an application should fail in some manner when it's detected, is certainly debatable. > The threat model is impersonation, where the legitimate key has been replaced by someone else's key, and the ensuing communication is neither authentic nor private. The application should refuse to run if it's not finding a valid, sufficiently protected key. Otherwise, the owners of the system can't claim non-repudiation as to the genuine provenance of communication. -Philip
