Feature request: "Same as parent process" instead of "Apply same rules to child processes"

[skycommand]

Hello. 😊

Thank you for the great work you've done with Fort Firewall.

Problem

Windows has several risky processes that don't do anything themselves, but connect to the Internet on behalf of other processes, e.g., rundll32.exe and msedgewebview2.exe (Microsoft Edge WebView2). If the process launching them is trustworthy, these proxy processes should be allowed access. Otherwise, they should be denied.

For example, I'd like Microsoft Word to fetch my content from the Internet. Microsoft Word relies on msedgewebview2.exe to do that. So, if Microsoft Word launches msedgewebview2.exe, I'd like it to have Internet access. But I wouldn't want the latter to have Internet access if launched by a shady or low-quality app.

Current solution: "Apply same rules to child processes"

As of version 3.13.10, Fort Firewall can grant or deny Internet access to a process depending on the existing access permission on its parent process. However, the way to do it is via the "Apply same rules to child processes" checkbox. I think this method is potentially dangerous because we never know what child processes any given process can spawn. For example, imagine you're in the Save As... dialog box of Microsoft Word. You right-click a file and select "Open". That'll spawn a child process. We don't for certain whether it deserves Internet access.

My proposal: "Same as parent process"

I propose that upon defining an access rule for a process, in addition to "Allow" and "Deny", we should have a third option called "Same as parent process". So, when msedgewebview2.exe or rundll32.exe wishes to connect to the Internet, Fort Wall checks whether it has been launched by an allowed process. If, for example, msedgewebview2.exe is launched by Microsoft Word (which already has Internet access), then allow. If it is launched by some blocked process, then deny access.

[tnodir]

Hello and welcome )

Good idea. Because it's somewhat easy to implement, then let me to add it soon and see how it'll work..

[tnodir]

But parent process should have the "Apply same rules to child processes" flag anyway, otherwise the new "Apply same rules from parent process" will not work.

So other new flag "Apply same rules only to specified child processes" is required.

[tnodir]

Please check the v3.13.11-test03.

[tnodir]

@Emi-Emi-Emi Can you please review these changes too?

What do you think?

[tnodir]

If all of these flags will work fine, then I'm going to show the 3 "Allow same rules ..." flags as one combo-box:

• Allow same rules: { "from parent process" | "to child processes" | "to specified child processes" }

[skycommand]

Please check the v3.13.11-test03.

Thanks. I'm anxious to test it when I get home on Monday.

[skycommand]

I found a PC I could use to test v3.13.11-test03.

I worked with the new version of Fort Firewall a bit and I seem to understand how it works now:

• Add the "Use the same rule from parent process" flag to the child process (e.g., Microsoft Edge WebView2)
• Set the child process's access rule to Block. (Allow doesn't work.)
• Add the "Apply same rules to child processes" flag.

I confirmed that Microsoft Edge WebView2 connects to the Internet when launched from Microsoft Word or OneDrive, but not otherwise. Good. I still don't know how to get the "to specified child processes" flag to work.

[tnodir]

I confirmed that Microsoft Edge WebView2 connects to the Internet when launched from Microsoft Word or OneDrive, but not otherwise.

But this behavior should be from "to specified child processes", not "to child processes".

I.e. the "Apply same rules to child processes" flag does not check the child's "Use the same rule from parent process" flag.

[skycommand]

You're right. I just checked. I had left the "to specified child processes".

It didn't occur to me to test the firewall with this flag off.

[tnodir]

It'll look as the following:

[skycommand]

It's a bit confusing. May I recommend a different wording?

Current wording	My recommendation
"Apply same rules"	"Connection rule inheritance"
"From parent process"	"Receive from the parent process"
"To specified child processes"	"Propagate to designated child processes"
"To child processes"	"Propagate to all child processes"

[tnodir]

@skycommand "Connection rule inheritance" -> "Rules inheritance" ?

[skycommand]

The reason I recommended "Connection rule" instead of "Rules" is to make it clear that schedules and flags don't inherit.

[tnodir]

Please check the v3.13.11-test04.

[Emi-Emi-Emi]

Tested it. It works fine, but only to the immediate child process.

For example I used Powertoys Run to test this easy.

PowerToys.exe (PowerToys.Runner)
├── PowerToys.PowerLauncher.exe
        ├── Skype.exe
        ├── Brave.exe
            ├── tor-0.4.8.10-win32-brave-2
        ├── WindowsTerminal.exe
            ├── OpenConsole.exe
            ├── cmd.exe

I added the PowerToys.PowerLauncher.exe to Propagate to designated child processes, Skype to disabled, and Brave to Receive from the parent process.

So in this case it is doing what it is suppose to be doing, but after this first child process inheritance, then it doesn't because Tor is going to connect to the internet even if it is set to disabled.

So, receive from parent will act as "to all child processes" (?).

So if you were to use this feature with PowerToys.exe (PowerToys.Runner), then everything will be allowed, because the moment you add the receive from parent, to the PowerToys.PowerLauncher.exe then everything will be allowed, even if Skype is set to disabled. So in other words, opening Terminal through Powertoys Run and then launching a program will be allowed in that case because at some point the "receive from parent" will just allow everything after that.

So I believe for this to work effectively (as we have discussed) there should be (if possible) another option to get the connection from the parent and don't inherit to the any child process, and then the other one that will just let the connection passthrough until it hits a receive from parent and stop or a disabled.

So this is the only observation I can make, it is a great addition to Fort, but seems like it is doing what we discussed once about how the whole child process tree works and how effective it will be if X or Y situation.

[tnodir]

The reason I recommended "Connection rule" instead of "Rules" is to make it clear that schedules and flags don't inherit.

@skycommand Let me rename it to "Rules", because it means only "Connection rule" anyway.

[tnodir]

So, receive from parent will act as "to all child processes" (?).

@Emi-Emi-Emi It's a bug. Forgot to add the inheriting of all flags..

Thanks for testing.

[tnodir]

Implemented in v3.13.11.