Re: [EXTERNAL] Re: [RFC] systemd-resolved: Send d-bus signal after DNS resolution

[Suraj Krishnan <suraj.krishnan@xxxxxxxxxxxxx>]

Our use case is to selectively open up the firewall for IP addresses that are in some pre-configured "allow" list of hostnames. Reading through the issue description in your link below, I believe the problem we're trying to solve is the same. It seems that your approach involved managing the firewall within systemd by updating the firewall prior to responding to the client making the DNS query. In our work described below, we send the notifications asynchronously, and the external daemon handles updating the firewall as you noted below. The userspace queue feature provided by nftables comes in handy for this external daemon.

Suraj

-----Original Message-----
From: Topi Miettinen <toiwoton@xxxxxxxxx> 
Sent: Friday, August 19, 2022 6:30 AM
To: Suraj Krishnan <suraj.krishnan@xxxxxxxxxxxxx>; Lennart Poettering <lennart@xxxxxxxxxxxxxx>
Cc: systemd-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: Re:  [EXTERNAL] Re: [RFC] systemd-resolved: Send d-bus signal after DNS resolution

[You don't often get email from toiwoton@xxxxxxxxx. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

On 18.8.2022 19.39, Suraj Krishnan wrote:
> Hi all,
>
> I wanted to revive this thread and provide an update on the status of this feature/PR.
>
> The feature adds a mechanism for privileged users to monitor DNS resolutions on the system, by adding a new varlink interface that exposes a method for clients to subscribe to such notifications. The feature will be off by default. Lennart's suggestion to use varlink for this turned out to be quite valuable and we've been successfully using this patch for the last few months. We're using it to update the firewall (drop by default) based on pre-configured allow-list of hostnames. We also leverage nftable's queue feature to address race conditions associated with asynchronously updating the network firewall.
>
> I received great feedback from the community on the PR, much of which is already incorporated. There are two more suggestions that aren't incorporated yet:
> 1) Add "resolvectl monitor" functionality to provide a built-in way to 
> monitor the notifications and try out the feature easily (note that 
> varlink CLI tools are just as easy to setup/use)
> 2) Add a d-bus property when the feature is in use. This allows unprivileged clients to be aware that DNS requests are monitored on the system.
>
> At this point, I'm writing to gauge if the devs would be open to accepting this patch in its current form, or would like to have 1) and/or 2) incorporated into the same PR, or have any concerns about the feature in general.
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fsystemd%2Fsystemd%2Fpull%2F22845&amp;data=05%7C01%7Csuraj.kri
> shnan%40microsoft.com%7C0a71cf58d28e4fe0b7ae08da81e6f134%7C72f988bf86f
> 141af91ab2d7cd011db47%7C1%7C0%7C637965126144493097%7CUnknown%7CTWFpbGZ
> sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> D%7C3000%7C%7C%7C&amp;sdata=ymiEcAWdPadHj6qvpHacAhaReDFQKKLkOONaaRNtXX
> 0%3D&amp;reserved=0

I planned to do something similar with
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsystemd%2Fsystemd%2Fissues%2F17053&amp;data=05%7C01%7Csuraj.krishnan%40microsoft.com%7C0a71cf58d28e4fe0b7ae08da81e6f134%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637965126144493097%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=GadmD2yDV16mEJmY8F0OMBAH40YIHLFFHt0lhO0exBU%3D&amp;reserved=0
and https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsystemd%2Fsystemd%2Fpull%2F17126&amp;data=05%7C01%7Csuraj.krishnan%40microsoft.com%7C0a71cf58d28e4fe0b7ae08da81e6f134%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637965126144493097%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=7o4nNoFNzgDFRt05jkgajobs96NWU1%2FDfMuPTdlxLFM%3D&amp;reserved=0
but I didn't find a good solution for updating the firewall by resolved itself or indirectly with NFT sets. An external daemon is probably the best choice and then varlink interface makes a lot of sense. I don't need the monitor or d-bus properties.

For simple resolver clients like systemd-timesyncd, which only needs a few names resolved and then it's happy to use the resulting IP addresses forever, the firewall doesn't need much managing, perhaps a NFT flush when the client exits or restarts. It would be nice to use the filtering and firewalling for more complex use cases like browser but then the lifetime of the firewall rules and when to drop them isn't very clear to me. Identifying the client robustly to the level I want seems to be also difficult, the best would be to use a combination of stuff like cgroups, UID/GID and SELinux domain of the client. May I ask what's your use case for the firewall integration?

-Topi

>
> Thanks
> Suraj
>
> -----Original Message-----
> From: Lennart Poettering <lennart@xxxxxxxxxxxxxx>
> Sent: Wednesday, February 16, 2022 9:53 AM
> To: Suraj Krishnan <surajkr@xxxxxxxxxxxxx>
> Cc: systemd-devel@xxxxxxxxxxxxxxxxxxxxx; Andre Muezerie 
> <Andre.Muezerie@xxxxxxxxxxxxx>
> Subject: [EXTERNAL] Re:  [RFC] systemd-resolved: Send 
> d-bus signal after DNS resolution
>
> [You don't often get email from lennart@xxxxxxxxxxxxxx. Learn why this 
> is important at http://aka.ms/LearnAboutSenderIdentification.]
>
> On Di, 15.02.22 22:37, Suraj Krishnan (surajkr@xxxxxxxxxxxxx) wrote:
>
>> Hello,
>>
>> I'm reaching out to the community to gather feedback about a feature 
>> to broadcast a d-bus signal notification from systemd-resolved when a 
>> DNS query is completed. The message would contain information about 
>> the query and IP addresses received from the DNS server.
>
> Broadcasting this on the system bus sounds like a bit too heavy. I am sure there are setups which will resolve a *lot* of names in a very short time, and you'd flood the bus with that. D-Bus is expressly not built for streaming more than control data, but if you have a flood of DNS requests it becomes substantially more than that.
>
> Also, given that in 99.9%of all cases the broadcast messages would just be dropped by the broker because nothig is listening this sounds needlessly expensive.
>
> What would make sense is adding a Varlink interface for this however. resolved uses varlink anyway it could just build on that. Varlink has the benefit that no broker is involved: if noone is listening we wouldn't do anything and not have to pay for it. Moreover varlink has no issues with streaming large amounts of data. And its easy to secure to ensure nobody unprivileged will see this (simply by making the socket have a restrictive access mode).
>
> So yes, i think adding the concept makes a ton of sense. But not via D-Bus, but via Varlink. Would love to review/merge a patch that adds that and then exposes this via "resolvectl monitor" or so.
>
> Lennart
>
> --
> Lennart Poettering, Berlin