Allow/block connect through child process

[tnodir]

"PC Tools Firewall Plus" program have a feature to prevent processes to use Internet via child processes:

• you can turn off the "Allow connect through child" flag for Program.

---

What do you think about this feature?

How it should be implemented in Fort Firewall's UI?

[Emi-Emi-Emi]

@tnodir

The feature could be useful, don't know how the usage would be since Apply same rules to child processes is in Fort, but I guess just a checkbox in each program window with "block child processes", just like there is "kill child processes" should be fine?, this means people can allow a program and still block everything that is opened as child process by it, even if it the child process is allowed globally.

or maybe something better, make Apply same rules to child processes more flexible by making a drop down menu Rules to child processes and have the options to Allow, Block and Kill, and 'same as parent' or something, so you people can easily choose what to do what to do with child processes, this means: allow when parent is blocked, block when allowed, kill when whatever, and if you allow or block the parent, the child process will just follow that automatically.

Of course, I must say, that the only scenario I could think this feature being useful is if someone wants to allow a program globally, but only block it when it is started by X program, while still allowing X program/parent process to have internet connection.
And this means, I don't know how many programs would need to have internet connection (as parent processes) while starting child processes that would have to be blocked by the firewall, when most programs will just open a blockable exe as a child process anyway, which means a child process can be blocked globally, normally, as any other program, and if a program needs that process to be allowed then they can use Apply same rules to child processes if needed for specific processes too.

[Emi-Emi-Emi]

Yeah, but the probability of this is minimal, especially in today's Windows.

This is what I mean, for example today you get this when using tons of apps now with msedgewebview2.exe, so you have to allow it in order to use something like Quick Assist, installers and all and Powertoys Peek and all, some would need internet connection and others don't. But msedgewebview2.exe is based on Chromium, so it has sandboxing and isolation coding, which means it will avoid installing and doing weird things unlike IExplore.exe did in the past, in already deprecated Windows versions.

Now, the only way I can think about this is either, to make the Apply rules to child processes more flexible like I said, but then have a global option to set what behavior will be set by default to each program, so if people are paranoid they can set it to 'block child processes' by default, and then individually change it in each program's to Allow if necessary. Just like how Filter's Mode work with program rules.

Of course, the problem is if we talk about 'risks' then there could be also some child processes that would be more risk to allow to connect to the internet than others, the problem is that this feature would still be an all child processes or nothing thing.
This means the only way to truly make a feature like this work to avoid malicious child processes and tweak it to its finest would be by having a 'custom box' in each program to exclude the child process individually from whatever is set, and this way a person can allow, block or kill all child processes but exclude IExplorer.exe from that action, or block and only allow msedgewebview2.exe so only that child process will be allowed internet and not others child processes.

And then, having a 'custom box' for global child rules is necessary (not only in the individual program), so each program will inherit that and let the user personalize how a new detected program will be treated, while still allowing to be overridden per program.

And as you can see it can get really complex, but no other Firewall have done it properly as the way I think it should be done to properly make it work.
But in Fort Firewall today, having the apply same rules to child processes seems okay to me because it can do most of the work, only having a wildcard program with C:\Program Files\WindowsApps\MicrosoftCorporationII.QuickAssist_*_x64__8wekyb3d8bbwe\Microsoft.RemoteAssistance.QuickAssist\QuickAssist.exe and the checkbox, will only allow Quick Assist without allowing other webviews in other programs, not perfect but better than other firewalls, even if all child processes would be allowed or blocked or kill.

[tnodir]

And as you can see it can get really complex

Yeah, I don't like that complex, over-engineered solutions.

OK, let's see other scenario:

1. I use a curl program from Far files manager:

• there is no rule for Far app in the Programs window
• there is an allowed rule for curl in the Programs

2. I've installed some new Test app and run it from Far:

• there is no rule yet for Test app in the Programs
• Test also uses the curl to download some files

Current behavior: Test can connect via curl.
Expected: Test can not connect via child processes.

Suggested solution:

• add "Trusted to connect through child processes" flag to Program
• check all parents of allowed app to be "Trusted" to be able to connect
• current "Apply same rules to child processes" (apply-to-child) flag overrides the "Trusted" flag

Use cases:

• untrusted Far -> curl: Block
• trusted Far -> curl: Allow
• trusted Far -> untrusted Test -> curl: Block
• trusted Far -> trusted Test -> curl: Allow
• trusted Far -> untrusted Test -> trusted Far -> curl: Block
• allowed apply-to-child Far -> untrusted Test -> curl: Allow

What do you think?

[tnodir]

add "Trusted to connect through child processes" flag to Program

So user have to mark all app launchers as trusted.

We can add a default launcher "%SystemRoot%\Explorer.exe" as trusted by default.

[Emi-Emi-Emi]

check all parents of allowed app to be "Trusted" to be able to connect

So this will detect the whole tree or how many parents have to be 'trusted' for it to work? because in this case the problem would be that not everything opens under Explorer.exe, something like PowerToys Run is currently opened on my side as a svchost.exe child.
This means if I opened Terminal and opened Far as I do, to use curl, the tree will be like:
wininit.exe -> services.exe -> svchost.exe (and then in one of the millionth svchost) -> PowerToys.exe -> PowerToys.PowerLauncher.exe -> WindowsTerminal.exe -> cmd.exe -> Far.exe -> curl.exe

So as I understand, you would have to trust from wininit to curl in order for curl to be allowed when ran through Far that was opened from Terminal that was opened through Powertoys Run?

We can add a default launcher "%SystemRoot%\Explorer.exe" as trusted by default.

Explorer needs internet connection for some stuff, I have it blocked in Fort since long time ago, so how can Explorer remind blocked forever and be 'trusted' to work if a program needs it trusted in order for it to connect to the internet?

What if I want curl to be allowed everywhere only for being allowed like today? or only through CMD but not anywhere else, but then I had to trust powershell because of a script that needed to connect to the internet and since curl.exe is trusted too, that means curl will be allowed to connect through powershell automatically as well because both are trusted now.

In other words, how will this be implemented? like, would it be the default mode or a new filter mode? because I really wouldn't want to use the firewall in this way of trusting apps for the child processes to run, because everything is a child process of something.

So in my opinion it seems like a more complex idea in practice, plus it would eventually fall in the 'once trusted, it can be trusted in any other program without any awareness by the user'.
This is because adding/trusting exes to the Programs that have nothing to do with internet, but still can match at any time, is still risky, plus it means it will clutter the Programs window, and make the managing of the firewall weird.
But the biggest issue is that you can open any program, by different methods, which means, depending how you opened a program, a child process will match or not. You can use CMD, Terminal (with other command line solutions like Cmder, ConEmu), Powershell, Different versions of Powershell , win+r (= run), a shortcut on desktop, from a 3rd party launcher or 3rd party file manager, and there could be other ways people might launch a single program, so if you opened Far.exe or curl.exe differently, then stuff could get allowed it randomly like happens today, or you would have to spend time setting things up because you would have to go to statistics window to see what parent has to be 'trusted' because you opened the parent differently.

And If everything has to be added 'manually' by the user in the end, with 100 parents processes that have to be 'trusted' in order for this to work even if the processes have nothing to do with the internet, seems like not too efficient and still prompt to error just like today, since exes can still be allowed by matching the 'trusted' flag, a trusted flag that was probably set for totally different reasons but now they are automatically allowed, because the idea of trusted flags still has no control to just filter the child process specifically by application, and it is still some global thing that can either do what it is supposed to do or go wrong like today.

Honestly, I think that not being lazy and do it today like: allowing curl.exe temporary and schedule so it get blocked or using CMD to quickly do it now Fort allows that, or open Programs window and hit B to block it manually once you don't need it, etc would achieve the same, be more efficient since you are sure it will not be allowed in the future just because it matched two random trusted, like CMD or Explorer.exe or something else, and you as the Fort maintainer, don't have to implement anything.
The problem is wanting to have a exe allowed everywhere and still complain that a program might still use it with internet access, in that case, then people should understand that X or Y programs, shouldn't be allowed, unless you need them or allow them globally always and be at risk.
Just like if I allow Far with apply same rules to child processes then I understand the risks of ANY child process, good or bad, can run without me having to manually allow them or block them.

At least that's how I see it. You know, just raising the concerns and my opinions and doubts about it but also my honest thoughts about it.

About my suggestion

I want to clarify that the only reason why my idea/suggestion became complex was for overthinking a way to set things up globally, to set things up before anything happened to facilitate the user, but to be honest I would just do it by app, improve the Edit Program/Wildcard and done and don't do any global setting, if people want to allow an exe and only be allowed when opened by X application and not anywhere else, people can set it up manually, but no 'other' parent process involved or anything and no prompt to errors of allowing processes randomly just like happens today.

The problem with the apply same rules to child processes implementation today is that there is that there is no way to allow or block only specific child processes, you have a checkbox, and that checkbox will allow every child process to have the same state as the parent, so my suggestion was simply to add a way to specify a child processes per program to filter it and improve what we have today.

This is because Fort already has most of this implemented, a way to block, allow or kill child processes, but only allow and kill will work when allowing a parent to internet, because block will only work if you block the parent.
So my idea was first a specific Block child processes option so it would Allow a parent but Block all child processes, just like you can do it today by default, but then add a way to specify a process (with a text box or something) to be allowed (or blocked) when ran as child process and nothing else, in my case I called it a exclusion list, excluded from the Allow, Block or Kill rule state.

So the idea on itself is not complex, it is mostly a way to lookup for a child process what would make it 'complex' I guess, but this is exactly what you want to do, but adding more parents in the process.

So to give the example: if Far.exe has block child processes selected, but excludes curl.exe then curl.exe will work only if curl is a child process of far.exe, and then if child processes are allowed to look for paths in Fort, then maybe do what Wildcard programs do today, either **curl.exe so any curl from any location can be used as child process or be specific and add C:\Windows\System32\curl.exe or %windir%\System32\curl.exe, so only specific curl.exe from a specific directory will be allowed, and not some random curl.exe from anywhere, if the users wants and for security reasons since the purpose of this feature is to avoid malicious programs to connect to the internet.

So I am not saying my idea is better or anything, just explaining that it wasn't as complex as it seemed, and most of the complexity happened for the 'global' that I said that could be added, but scratch that and only think it per application, this way it doesn't seem as complex and it will be efficient and less prompt for errors of being randomly allowed eventually.

In fact since you want to do something similar of matching child processes and parents and all, then seems like less complex in theory than your suggestion, since it will be done per application, and since application already offers 40% of this functionality then it is only about improving that. Also, this means Fort outside specific Edit Application window, will not change in any way or form, Programs list will stay the same, Options, and all that.

So wanted to make that clearer, and give my honest thinking comparing both ideas.

[tnodir]

So as I understand, you would have to trust from wininit to curl in order for curl to be allowed when ran through Far that was opened from Terminal that was opened through Powertoys Run?

I think, we can hardcode in the driver to trust "%SystemRoot%\System32\**" ?

so how can Explorer remind blocked forever and be 'trusted' to work if a program needs it trusted in order for it to connect to the internet?

Yes, Explorer can be "Trusted to connect through child processes" and Blocked itself to connect at the same time. It's a valid state.

[tnodir]

In fact since you want to do something similar of matching child processes and parents and all, then seems like less complex in theory than your suggestion

@Emi-Emi-Emi Thank you for analysis.

But I don't like specifying parent-child relations, because I want to have one list of app paths in the driver. No graph of paths.

[tnodir]

Honestly, I think that not being lazy and do it today like: allowing curl.exe temporary...

@Emi-Emi-Emi Yes, I agree.

Let's forgot about parent-child relations, trusted/untrusted etc.

Maybe we can add optional feature to mark some directories as "sandboxed":

• add "Folders" button in the Programs window, which will open a Folders window
• in the Folders window you can add only directories
• as Folder's option: check that apps from the "sandboxed" directories can connect to Internet only via self or only other apps from that (sub-)directory

[Emi-Emi-Emi]

The problem I see with only allowing directories is that many directories have too many exes like System32, if a malicious programs infects or adds something and placed in system32, then the 'sandboxed' directory wouldn't stop malicious programs from running, it would actually allow them to run freely, since now you wouldn't get any notification of 'blocked app' it would just run it.

Using your example, how can curl.exe be allowed only when ran within Far.exe only? That would be the purpose of the feature, and since Far and curl are completely different directories, which means in my case, since I use Far portable, then I would have to allow %userprofile%\Downloads\Far\ and %SystemRoot%\System32\ that means Far can run any exe within system32, and don't be blocked by the firewall, opening the computer even more to the internet instead of restrict it more.

The way I see it is this feature will only work if it can be specified by app, and then be able to specify individual exes and directories if needed, if not there is no benefit with only adding and allow Far.exe with Apply same rules to child processes, and have curl.exe blocked, or just temporarily allow curl.exe and blocked it when done.

[tnodir]

@Emi-Emi-Emi Thank you for feedback.

Indeed, if I've installed some untrusted app and want to prevent it to connect via child processes, then I can:

• add its folder as wildcard path
• Block it and set "Apply same rules to child processes"

Ok, I'm closing this discussion.
Thanks!

[Emi-Emi-Emi]

I was thinking....

How feasible would be to create something like: 'chained actions/rules' - one action that will be able to automatically change the state of other rules.
You kind do this with groups, but the 'feasible' part in question that I am thinking is to detect an exe is running, and then the adblocker will automatically change rules states based on the exe running. I guess the trickiest part besides detecting running exes, would be to toggle states after the program is detected not running, especially if some rules overlap. But sometimes a feature has to be develop and users has to make it work the 'best' they can without conflicts.
This way Far would run, and then automatically change the state of curl to enable, once it gets closed, then disabled, which would be similar to this but without using 'child' and 'parent' logic on it which seems to be a problem, and just change the same rules that are listed in Programs.
Technically it wouldn't be the same as this feature as the one suggested here, since you will enable curl.exe globally, but what are the chances that some malicious program will work exactly when the curl.exe is running because of far? users also have to be responsible and don't expect the firewall to cover every possible angle even if there is a 1% change of happening, especially when we talk about explicitly Allowing in an up to run globally, but expect it to be blocked in X or Y program.

Of course groups still exist today, and maybe if 'automatically detect exes when running' is not possible, what about launching a program from Fort and then Fort switching the rules the user added to the 'chain', so it won't need to much processing to do it, since no detection is needed.
If Fort can kill programs, why not launching them too? and if possible attached to rules, maybe even launch programs on schedule to make it an alternative to Task Scheduler, but easier, but if Fort.exe is the parent all the time, maybe that will make it easier to deal with the whole parent/child relations and 'trusting' programs, since people will for sure only launch trusted programs and not some random exe through Fort, and that means curl would run in a safer environment without touching 'global rules'.

Of course I am just throwing ideas with that, you are the only one who knows how everything exactly works to know exactly the limitations and how much complexity you want.

Something more important and I think feasible I was thinking about yesterday, is that Fort is that once a program is added to the list of programs, you don't get any notification about it afterwards, so, another way to make it easier for users to 'enable' some rules like curl when using it only in Far manager or some other program, is by getting notifications when a blocked program is being blocked again, since Fort now displays the Edit Programs in front and you can easily schedule the Enable, then it could be a good thing, it would be easier to enable curl just when needed, and if the program gets blocked and you still need it, you can get notification again, and then extend it.

I believe while this can potentially make some programs 'nag you' every second about being blocked, that's something that should happen if the user wants, which means there should be some 'delay/notify me again if program is blocked in/every X minutes' or some control when the user hits block or close it per program to get notified again or never see it again if the user thinks it won't be needed or it is something like SSDP Service DLL that will get blocked so much it will get impossible to do anything without 'never see it again'. Sometimes seeing an exe is being blocked every second is useful for troubleshooting reasons, especially with IP rules and all that, but sometimes you just want to get notified when to enable it and that way schedule the block and forget about it for a while until next time. So yes, people should get nagged every second if they want or delay it or turn it off /never-again per program if they don't need it.

Which means: having something like Collect Blocked Connections but for the Edit Program notification popup.

This can technically be done by removing the rule scheduled, but yeah, that's the problem, having to remove a rule you don't even know you won't need in the future to get notified about it again in the future is problematic, and even if users can see the Statistics window, sometimes Statistics window is not easy to follow, especially when many connections happen at once from different sources, since Statistics window still doesn't have a search function, then it can get complicated for some users that might just need the popup, schedule it and done.

Anyway! Thanks for your amazing work as always.

[tnodir]

After reading your post, I remember that I have a plan to implement a “Allow/block only this PID (process id)” feature of some other firewall. I forgot which firewall has it, maybe WFC or Agnitum.

I’ve planned to implement it after “Ask to Connect”. So you can decide to allow/block only the selected PID of pending connection.

So you will be able to set always “Ask” action to curl. And decide on PID in the each notification, maybe inspecting its parent.