Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Limit the number of processes per sandbox #1230

Closed
bastik-1001 opened this issue Sep 26, 2021 · 3 comments
Closed

Limit the number of processes per sandbox #1230

bastik-1001 opened this issue Sep 26, 2021 · 3 comments
Labels
Feature Request New feature or idea Status: Added in Next Build Added in the next Sandboxie version Type: Documentation Improvements or additions to documentation

Comments

@bastik-1001
Copy link
Collaborator

Is your feature request related to a problem? Please describe.
Version 0.9.7 is going to remove a technical limitation I am going to quote from the changelog fixed a design issue limiting the maximal amount of processes in one box to 511 and once Sandboxie had a feature to terminate processes in a sandbox https://sandboxie-plus.com/sandboxie/processlimit1/ which can be useful to prevent resource exhaustion.

Right now a process can spawn quite unlimited other processes in a sandbox, which can lead to resources being occupied, mainly RAM and CPU, what would not be desired in all instances, when a program malfunctions and spawns processes erroneously.

While it appears difficult to monitor CPU usage and RAM usage and set boundaries for those, counting processes appears rather easier.

Describe the solution you'd like
Mainly for Sandboxie to do something when processes in a sandbox get above a certain threshold that is defined per sandbox. This can be terminating newly spawned processes in the box, this can be terminating all processes, in the best case per user defined behavior.

The original feature had two values, which might not be required, as I am not sure if delaying the creation of new processes would be helpful, but certainly that could be an option, if that is considered to be useful.

@DavidXanatos DavidXanatos added the Feature Request New feature or idea label Sep 26, 2021
@DavidXanatos
Copy link
Member

Sounds potentially useful, ideal one would implement this in the driver,
but I don't like the notion of counting all processes per box on each creation just for that,
you see there is only one container with all processes so to get a count per box one needs to iterate through all check the box they belong to and so on.
The driver does not have a shared sandbox structure currently ...

But the SbieDll already does such counting on start to know if its starting the first process in the box or not,
so at that point we have a count value, I'll add there the limitation,
I would go with 1 limit that after its 80% full will add a delay of 3 sec to every subsequent process creation

@DavidXanatos DavidXanatos added the Status: Added in Next Build Added in the next Sandboxie version label Sep 26, 2021
@bastik-1001
Copy link
Collaborator Author

As long as there is no non-negligible performance impact, it should be done in the best way you can think off. This appears to be true if one component has to do some counting already.

@DavidXanatos
Copy link
Member

Yea doing it in sbie dll will not have a performance impact.

Generally sandboxie does not seam to be well written with regard to scaling with a larger count of running processes. A lot of linear lists instead of hash tables or iterate through all implementations where it was not necessary.
Something that needs fixing, a lot of it was already done see change-log, but one of the bigger things that remain open is the lack of a shared sandbox structure for each runnign box in the driver.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature Request New feature or idea Status: Added in Next Build Added in the next Sandboxie version Type: Documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

3 participants