Bug 251 - Should openssl init move to before privilege drop?
Should openssl init move to before privilege drop?
Product: unbound
Classification: Unclassified
Component: server
Other All
: P2 minor
Assigned To: unbound team
Depends on:
  Show dependency treegraph
Reported: 2009-05-20 10:58 CEST by Noa Resare
Modified: 2009-06-09 12:08 CEST (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Noa Resare 2009-05-20 10:58:18 CEST
As I understand the current unbound code it drops it's privileges long before the daemon_remote_create() function in remote.c is called. I am not familiar with the specifics of the OpenSSL API but if it is possible I would prefer the private key init to be preformed before the privilege drop occurs in unbound.c:perform_setup() since it would make it possible to have tighter access restrictions on the private key file.

One could argue that the private key data is in many cases already available to an attacker that successfully runs code as unbound, but I would counter that with the fact that it is definitely more difficult to have a buffer overflow exploit read it's own memory and finding the private key data than it is to simply open the private key file and acces it's content.

Such a change would also put unbound in line with other ssl-enabled daemons such as apache httpd when it comes to private key permissions.
Comment 1 Wouter Wijngaards 2009-05-20 11:10:18 CEST
Thank you for the report.

This looks like it is easier on admins as well as more secure. I would like to take up this change for unbound 1.3.1.  The upcoming unbound 1.3.0 is in a bit of a feature freeze to get it out the door; I do not like to make changes to the basic daemon setup process this late in the release process.  My apologies for the delay incurred.

Best regards,
Comment 2 Wouter Wijngaards 2009-06-09 12:08:53 CEST
Fixed code is available in svn trunk r1646.

Best regards,