Hi! Thanks for this new release of Unbound!
I just upgraded unbound from previos version and now I'm playing with
unbound-control. I met one security problem - unbound-control allows to
control unbound process to any user in the local system... AFAIK all access
control is done by file systems ACL for SSL sertificate files?
control unbound process to any user in the local system... AFAIK all access
control is done by file systems ACL for SSL sertificate files?
Yes. Also the interface is 127.0.0.1 by default, so localhost only.
The system can work for remote administration also, but then you must
set control-interface "0.0.0.0" (any). and maybe adjust your firewall.
and to close this "security hole" I make a fast chmod/chown to this:
added chmod o-rw (files) to unbound-control-setup.
But I have to warn you about one extra problem. If make a chmod/chown changes
corresponding to this new unbound-control-setup.sh:
-rw-r----- 1 root wheel 891 21 ноя 17:57 unbound_control.key
-rw-r----- 1 root wheel 627 21 ноя 17:57 unbound_control.pem
-rw-r----- 1 root wheel 887 21 ноя 17:57 unbound_server.key
-rw-r----- 1 root wheel 619 21 ноя 17:57 unbound_server.pem
then, during system restarting, unbound do not starts automaticaly and I can
see this error messages insight of unbound.log:
[1227454036] unbound[1035:0] debug: module config: "iterator"
[1227454036] unbound[1035:0] notice: init module 0: iterator
[1227454036] unbound[1035:0] debug: target fetch policy for level 0 is 3
[1227454036] unbound[1035:0] debug: target fetch policy for level 1 is 2
[1227454036] unbound[1035:0] debug: target fetch policy for level 2 is 1
[1227454036] unbound[1035:0] debug: target fetch policy for level 3 is 0
[1227454036] unbound[1035:0] debug: target fetch policy for level 4 is 0
[1227454036] unbound[1035:0] debug: Reading root hints from /named.cache
[1227454036] unbound[1035:0] info: DelegationPoint<.>: 13 names (7 missing),
19 addrs (0 result, 19 avail)
[1227454036] unbound[1035:0] debug: duplicate donotquery address ignored.
[1227454036] unbound[1035:1] debug: cache memory msg=33040 rrset=33040
infra=1312 val=0
[1227454036] unbound[1035:2] debug: cache memory msg=33040 rrset=33040
infra=1312 val=0
[1227454036] unbound[1035:3] debug: cache memory msg=33040 rrset=33040
infra=1312 val=0
[1227454036] unbound[1035:0] error: Error setting up SSL_CTX key and cert
crypto error:0200100D:system library:fopen:Permission denied
[1227454036] unbound[1035:0] error: and additionally crypto error:20074002:BIO
routines:FILE_CTRL:system lib
[1227454036] unbound[1035:0] error: and additionally crypto error:140AD002:SSL
routines:SSL_CTX_use_certificate_file:system lib
[1227454036] unbound[1035:0] error: util/alloc.c at 131 could not
pthread_spin_destroy(&alloc->lock): Invalid argument
[1227454036] unbound[1035:0] fatal error: Could not initialize main thread
procstat for running unbound proces says this:
# procstat -s 1035
PID COMM EUID RUID SVUID EGID RGID SVGID GROUPS
1035 unbound 59 59 59 1 1 1 1
GID=1 - it is FreeBSD special 'deamon' group
UID=59 - it is dedicated user ID for unbound
GID=59 - it is dedicated group ID for unbound
This trouble disappears only if I make this set of ACL/ownership changes:
-r--r----- 1 unbound wheel 891 21 ноя 17:57 unbound_control.key
-r--r----- 1 unbound wheel 627 21 ноя 17:57 unbound_control.pem
-r--r----- 1 unbound wheel 887 21 ноя 17:57 unbound_server.key
-r--r----- 1 unbound wheel 619 21 ноя 17:57 unbound_server.pem
So... It may be only FreeBSD specific situation or may be not - I can not
investigate this issue more detailed.
I can see you correction in the trunk repository - thanks.
But I have to warn you about one extra problem. If make a chmod/chown changes
corresponding to this new unbound-control-setup.sh:
then, during system restarting, unbound do not starts automaticaly and I can
see this error messages insight of unbound.log:
[1227454036] unbound[1035:0] error: Error setting up SSL_CTX key and cert
crypto error:0200100D:system library:fopen:Permission denied
So... It may be only FreeBSD specific situation or may be not - I can not
investigate this issue more detailed.
Yeah you're right. I have added documentation, recommending to do sudo
- -u unbound unbound-control-setup. It probably won't set group to wheel
on FreeBSD, but the trouble is this stuff is very distribution specific.
Anyway - hope this report will be helpfull...
Yes, I added documentation, that is going to help operators figure out
what they need to do (check user permissions).