Given a service that needs access to some secrets from a config file to start, I can imagine three approaches:
1) Keep the file readable only by root. Start the process as root, read the config and drop privileges.
2) Keep the file readable only by daemon user, start the process as the daemon user.
3) Keep the file readable only by root. Start the process as the daemon user with the CAP_DAC_READ_SEARCH capability and drop it after reading the config.
My initial analysis of the alternatives:
+ If there's a vulnerability an attacker needs to read own process memory to get sensitive data (fairly hard?)
- More complex due to need for setuid/setgid
- If the software is compromised before dropping privileges it'll run as root
+ simpler to program, drop privileges from init script
- If there's a vulnerability an attacker can read sensitive data from disk (easy)
+ Never gives full root access to the process
+ If there's a bug an attacker would have to read process memory instead of just a file
- Plenty complex
- Still gives very broad access to reading files outside the config file (like
/etc/shadow and similar)
Are there any other options that should be considered, or pros or cons I have missed? Are there any good reasons to handle privilege dropping yourself instead of letting the init process handle it?