How to allow msedgewebview2.exe only for a specific .exe ?

[JB-DX]

An .exe with embedded webpages calls msedgewebview2.exe to display those.
For that I have to allow msedgewebview2.exe internet access, not the app itself.
But the huge drawback is: All other apps using msedgewebview2.exe have now also internet access.
I now lose control by that. A hacker knowing this can easy get around Tinywall.

Is there any way to allow only msedgewebview2.exe that has it parent set to my .exe ?

[pylorak]

This problem should plague other firewalls (EDIT: firewalls that don't install drivers) as well and is not specific to TinyWall.
Unfortunately that's just how it is. The best thing that can be done here is to not give access to msedgewebview2.exe and accept that functionality that relies on it will not work. This is a side effect of Microsoft's design about how to embed Edge into other applications. The most a user can do is 1) choose other apps that don't embed Edge, or 2) convince app developers to choose other solutions for integrating a webpage.

[tnodir]

This is problem should plague other firewalls as well and is not specific to TinyWall.

Fort Firewall's "Rules inheritance" feature was inspired by TinyWall.

And we improved it further in tnodir/fort#298, so only specified child processes can inherit rules.

[JB-DX]

@tnodir that's the way to go !
And it shouldn't be difficult to implement, just examine the parent tag of a process.
For a long time I have a similar issue with a bank app, it spawns a process for communicating with the bank. For security reasons that process-name is random. So no way to create a firewall rule except that its parent is the same.
I always have to set Tinywall to allow all outbound connections during that period. That's fine with me, as it doesn't happen often.

@pylorak You need to face reality and adjust Tinywall to cope with modern .exe, not the other way around.

[pylorak]

@JB-DX "You need to face reality" & "And it shouldn't be difficult to implement, just examine the parent tag of a process."
No need to be snarky, just stay constructive.

As you already know TinyWall already implements (was the first to implement) rule inheritance to child processes. So getting to the parent is not the problem (though TinyWall does does it differently than what you suggest, that's not an issue here). Let me ask you this: If what you propose is supposed to be a solution, then why can't you just use TinyWall's "child inheritance" feature. You might tell me, because you cannot constrain it to specific executables. But that is not the main issue. That feature has multiple problems, like being slow to react to children spawning, being unable to halt the child until the firewall rule changes are applied, a race condition related to process destruction and recreation, to name a few.
But all these are nothing compared to the gaping huge problem that, even if TinyWall let you pick & specify child processes, firewall rules still apply to executables, not to processes. Which means even if child inheritance would be constrained to only msedgewebview2.exe for a specific parent, when that parent triggers rule creation for msedgewebview2.exe, other parent processes would still immediately get access to msedgewebview2.exe as well even though msedgewebview2.exe isn't generally whitelisted.

I don't know if Fort Firewall got around these problems and if so, how. To the best of my knowledge, the only way to solve these issues is to install kernel drivers, maybe Fort Firewall does that. But as you probably know TinyWall does not, and that is not something I'm considering giving up on right now, because not using drivers has its own big advantages (and of course downsides as well - it's a tradeoff).

A good start for a solution would be if only Microsoft reported the offending PID (process ID) over the WFP interfaces when an app gets blocked, but it does not. Workarounds include enabling firewall logging which which thrashes your hard drive continuously, increases its wear, power draw, and in the case of rotational drives noise and temperature significantly, or writing custom kernel drivers as noted above. I find none of these acceptable solutions.

If somebody can tell me what API I could use without custom driver or what I am missing, I'll gladly fix this in TinyWall.
@tnodir How does Fort do this?

[tnodir]

@pylorak Fort Firewall uses own driver.

[JB-DX]

@pylorak I admit that I don't know the "child inheritance" feature. Can you tell me where I find info about configuring it?
Maybe that already would fit my needs. That would be great. I looked thru the configuration pages but found no hints.
I agree it would be best to avoid kernel drivers. Otherwise I don't know much about the details how firewalls operate. I'm just a user of it.

[pylorak]

@pylorak I admit that I don't know the "child inheritance" feature. Can you tell me where I find info about configuring it? Maybe that already would fit my needs. That would be great. I looked thru the configuration pages but found no hints. I agree it would be best to avoid kernel drivers. Otherwise I don't know much about the details how firewalls operate. I'm just a user of it.

If you edit a rule, you have a checkbox to enable inheritance for children, like in the screenshot below. Note though, as explained above, this is not an ideal solution for the use-case of msedgewebview2.exe due to the aforementioned problems. This feature was primarily developed to ease the usage of some installers.