Update Templates.ini (feedback requested)

[isaak654]

This introduces a new template for PDF24 Creator that should prevent this issue: https://www.wilderssecurity.com/threads/released-sandboxie-plus-sbie-fork-versions-with-signed-driver.434924/page-11#post-2976559

Right now it should be applied manually in Sandboxie.ini (most of the times) before installing PDF24 Creator, so before merging I'd like to find a way to apply this template automatically at Sandboxie startup. Otherwise for me this commit is ready to be pushed.

P.S: I've removed some obsolete templates, this is why the file is slightly smaller than before.

[isaak654]

Right now it should be applied manually in Sandboxie.ini (most of the times) before installing PDF24 Creator, so before merging I'd like to find a way to apply this template automatically at Sandboxie startup. Otherwise for me this commit is ready to be pushed.

@DavidXanatos

[DavidXanatos]

Is it done yet? Github says:
This pull request is still a work in progress
Draft pull requests cannot be merged.

[isaak654]

Is it done yet? Github says:
This pull request is still a work in progress
Draft pull requests cannot be merged.

It's done, but I'd like to find a better way to edit this new PDF24 Creator template I've added in order to be automatically recognized at Sandboxie startup.
Do you think it's possible or not?

[DavidXanatos]

mmh.... I think it may be best to consider enhancing the template system with a exe name based detection, so I think of a condition that is triggered when a process with a pre defined name gets started.
With the interactive prompt mechanism of the plus UI the program execution could be halted and the template applied in time, or in this particular case the execution blocked.

[isaak654]

mmh.... I think it may be best to consider enhancing the template system with a exe name based detection, so I think of a condition that is triggered when a process with a pre defined name gets started.
With the interactive prompt mechanism of the plus UI the program execution could be halted and the template applied in time, or in this particular case the execution blocked.

Basically this new template is meant to be applied in advance in order to work properly and it should put a band-aid on an issue in Sandboxie, because PDF24 Creator installs some keys (even if sandboxed) on the real system in different locations:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Printers\PDF24
HKEY_USERS\.DEFAULT\Printers\ConvertUserDevModesCount\PDF24
HKEY_USERS\.DEFAULT\Printers\ConvertUserDevModesCount\PDF24 Fax

While for the first one you can execute a ClosedKeyPath=\REGISTRY\MACHINE\SYSTEM\CurrentControlSet\Control\Print\Printers\*, you can't do the same with HKEY_USERS\.DEFAULT\ hive. My explanation is that it doesn't get emulated in Sandboxie environment at all, because I analyzed the RegHive file inside the DefaultBox with BSA tool (before and after program install) and there is no trace of creation of HKEY_USERS\.DEFAULT\Printers on the sandbox side, while in the real system there is.

At the very end, I have preferred some process exclusion in the template to get the job done. But other programs out there could behave like this one.

Anyway, if there is no existing method to improve the template for a better real-time detection, I'll mark this commit as ready.

[DavidXanatos]

I think the way this leak works is that in order for printing from the sandbox to work at all some IPC is open that results in a sandboxed program asking an unsandboxed windows component to set up the printer and said component creates the registry entries outside.

[isaak654]

I think the way this leak works is that in order for printing from the sandbox to work at all some IPC is open that results in a sandboxed program asking an unsandboxed windows component to set up the printer and said component creates the registry entries outside.

It would be great if you could trace & fix it without the need of a template, anyway it's up to you whether you want to merge or change something in the commit.

P.S. Happy new year!

[DavidXanatos]

is blocking ClosedFilePath=pdf24.exe,* required isn't ClosedFilePath=pdf24-PrinterInstall.exe,* enough?

[isaak654]

is blocking ClosedFilePath=pdf24.exe,* required isn't ClosedFilePath=pdf24-PrinterInstall.exe,* enough?

Both rules are needed in order to block HKEY_USERS\.DEFAULT\Printers\ConvertUserDevModesCount from writing into the real registry.

This is the full resource log that I obtain when I only apply the ClosedFilePath to pdf24-PrinterInstall.exe and multiple ClosedClsid/ClosedIpcPath in the template. FaxPrint and PDFPrint are still exposed:

Pipe        \Device\NamedPipe\FaxPrint:SYSTEM:1; PID: 3284
Pipe        \Device\NamedPipe\FaxPrint:SYSTEM; PID: 3284
Pipe        \Device\NamedPipe\FaxPrint; PID: 3284
Pipe        \device\namedpipe\faxprint; PID: 3284
Pipe        \Device\NamedPipe\PDFPrint:SYSTEM:1; PID: 3284
Pipe        \Device\NamedPipe\PDFPrint:SYSTEM; PID: 3284
Pipe        \Device\NamedPipe\PDFPrint; PID: 3284
Pipe        \device\namedpipe\pdfprint; PID: 3284

Unless you find a way to block these, my two-rules approach is the best one currently available. The problem is that I don't think many people will apply the template preventively.

[DavidXanatos]

mmh... but are they open though?
Normally open items are marked with a "O" in the status column, I would say those pipes are available in the sandbox but not outside.

I'm analyzing what's happening with this PDF24 situation and well, it kind of works as designed, when doing printing related stuff sandboxed processes are allowed to talk to the real unsandboxed printer spooler which apparently for some commands creates registry entries on its own.

For example a call to WinSpool.drv!AddPortExW creates an entry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Ports this is done by pdf24-PrinterInstall.exe

When the port is set up a sandboxes call to RUNDLL32 PRINTUI.DLL,PrintUIEntry /if /q /b "PDF24" /f "C:\WINDOWS\inf\ntprint.inf" /r "\\.\pipe\PDFPrint" /m "MS Publisher Color Printer" triggers the creation of the printers outside the sandbox.

The proper fix here is

1. to make access to the print spooler optional eider disabled in hardened boxes or disabled out right, such that if one wants to print from a sandbox it must be explicitly enabled.
2. if printing is enabled still block WinSpool.drv!AddPortExW from telling the unsandboxed print spooler (spoolsv.exe) to create new ports.

[isaak654]

Thank you for the technical explanation and for giving me the full picture.
I'll comment out the template in a separate commit once you will have released the proper fix.

[DavidXanatos]

I created a slack channel for sandboxie-plus, if you send me an email address than I can send you an invite.
That would be more convenient for communication.