resolved: access control feature #17126
Conversation
|
Centos CIs fails TEST-50-DISSECT and TEST-50-DISSECT_coredumpctl_collect. On bionic-arm64, test-path fails and bionic-i386 test "upstream" fails. Doesn't seem related to systemd-resolved to me. |
|
I am a bit puzzled about this? This controls which client can resolve a specific host? i.e. it doesn't control which IP addresses it can connect to, hence it can easily contact any DNS server on the internet directly (e.g. 8.8.8.8) and get the desired resolution data ynway? |
|
Direct access with known IP addresses will be blocked by the firewall mechanism, which is part 2 of #17053. Then the application can't access anything before they make a DNS request first. If the request is allowed by resolved and the domain is successfully resolved, the resolved IP address of the domain name will be added to firewall (perhaps just add to service specific IPSet for simplicity). This means that knowing the IP address does not help. |
|
I've played with a version which can filter also using UID, name of the command and possibly user unit of the calling task to see which fields could be useful. For some reason (maybe my overly restricted configuration) dbus-daemon can deliver only a very few fields out of the possibilities listed in sd-bus.h by using the message creds. More fields can be found via PID, but probably this is not race-free. I'm actually agreeing with @keszybz's suggestion to use only unit. The more there are fields, the more there are means to differentiate the calling process better and thus provide better DNS request filtering. But actually the different processes are still part of one service unit and thus there may be only a weak protection boundary or none. Then the configuration in service unit file could be simply: Also, the firewall can only be installed for the entire service. For that I'm sort of waiting for the libnftables integration in #17026. The firewall also needs a mechanism to install a new network namespace like |
topimiettinen
force-pushed
the
resolved-access-control
branch
from
3bdee94
to
b457598
Compare
|
In this version, the config file is replaced with a simple unit setting which is read by resolved: Perhaps However, when the filter rejects a request via Varlink, it may lead to segfault. Perhaps a bug in varlink implementation? |
|
I checked if #18135 would help, but it didn't. Backtrace from the segfault: Another: |
|
It seems that field But would that be the proper solution, or should |
topimiettinen
force-pushed
the
resolved-access-control
branch
from
b457598
to
b0c0725
Compare
|
In this version I addressed @bluca's comments, handled the Varlink problem and added |
|
Made #18171 to fix the userdata field problem at Varlink side. |
|
to refresh manpages run: |
|
@topimiettinen is this still relevant? |
bluca
added
needs-reporter-feedback ❓
|
@bluca Yes, but I no longer plan to integrate firewalls into this directly. I've used the patch for more than year now. |
what is it used for? can you update the use case, and rebase? |
topimiettinen
force-pushed
the
resolved-access-control
branch
from
89c63dd
to
a36a5b6
Compare
|
@bluca OK, force pushed an updated version |
|
@bluca All green! |
|
Can you add some testing in TEST-75-RESOLVED? |
|
@bluca I guess you mean testsuite-75.sh. OK, I'll try. |
topimiettinen
force-pushed
the
resolved-access-control
branch
3 times, most recently
from
4d54f9e
to
bfaf623
Compare
Implement simple access control for systemd-resolved. This can be used to allow-list or deny-list domains which a service can use. The feature is limited to bus clients (such as nss-resolve). The filtering can be used to check that services access only approved domains (don't phone home), a minor hardening option. A service could use DoH and direct DNS protocols to circumvent the filtering, so those need to be blocked with other means (firewalls, SELinux). Example directive for systemd-timesyncd.service: [Service] DNSAllowedDomains=*.ntp.org Most system services have no need for DNS, so this can be enforced with: [Service] DNSDeniedDomains=*
topimiettinen
force-pushed
the
resolved-access-control
branch
from
bfaf623
to
542eac4
Compare
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
topimiettinen
force-pushed
the
resolved-access-control
branch
5 times, most recently
from
30ec793
to
d436c82
Compare
topimiettinen
force-pushed
the
resolved-access-control
branch
2 times, most recently
from
d03d938
to
2e3301c
Compare
topimiettinen
force-pushed
the
resolved-access-control
branch
from
2e3301c
to
0d1b41e
Compare
|
It's interesting that the tests in TEST-75-RESOLVED are passing on CentOS CI (CentOS Stream 8) as expected (TEST-02-UNITTESTS and TEST-60-MOUNT-RATELIMIT fail, unrelated), but on CentOS CI (Arch Linux + sanitizers) and CentOS CI (Arch Linux) they don't. The first test fails:
|
Interesting, I just tried it on my local F36 machine, and got the same result as on Arch: So maybe it's some older glibc-related issue? |
|
Ah, it looks like it's a race: |
|
And it appears to be a cache-related stuff: |
|
@mrc0mmand Awesome, thanks! |
DaanDeMeyer
added
needs-rebase
and removed
please-review
Implement simple access control for
systemd-resolved. This can be used toeither allow-list or deny-list domains which the service can use. The feature
is limited to bus clients (such as
nss-resolve).Example /etc/resolved-access.d/basic.conf: