Python Mu with AppLocker

[ojtest6]

Hello,

Some background:
We use Python Mu within an education environment, our environment has various restrictions such as AppLocker.
AppLocker is generally used to block unauthorised files (.exe) from running, with exception rules to allow files to run based on the file path, file hash, or whether the file is digitally signed.
Ideally, files are allowed by file hash or based on the publisher (digitally signed). File path rules allow anyone to put an unauthorised file within the path and run it.

When Python Mu is launched, it creates a folder structure within %OSDRIVE%\USERS_Username_\AppData\Local\Python\Mu\Mu_VENV-38-(Timestamp)\Scripts\

The issue:
Some .exe's within the path above are not digitally signed, such as pip.exe and wheel.exe, and AppLocker prevents them from running.
The file hash changes per user.

Although it's possible to use file path rules to allow this, please consider digitally signing the other .exe files within the location if possible.

Thanks.

[carlosperate]

@tmontes / @ntoll Looks like not all .exe files in the Mu Windows installer are signed. Is this something that needs to be updated in pup or the signing process?

[tmontes]

More after a quick chat with an LLM (I'm mobile so no access to much more now, docs/code).

The venv's pip.exe is generated and thus, unsigned. However, Python.exe in the venv is copied, and signed by pup.

So maybe we're running "pip install" during the venv setup which fails... but "Python -m pip install" should work.

Could that be the case?

[tmontes]

Quick (mobile) browsing our code. The virtual_environment module seems to use self.pip_executable in many places... Maybe adapting the code to end up rendering "Python -m pip" can address this.

[tmontes]

Quick (mobile) browsing our code. The virtual_environment module seems to use self.pip_executable in many places... Maybe adapting the code to end up rendering "Python -m pip" can address this.

...if the new signing process signs all binaries we ship, something pup does (it signs all exe/dll/pyd files, including those bundled within the wheel files we ourselves bundle).

[carlosperate]

Just to add a quick note in case it's useful, the pip used inside the created virtual environments is actually vendored as a wheel by the virtualenv package, which is used by mu to do this: https://github.com/pypa/virtualenv/tree/main/src/virtualenv/seed/wheels/embed
But yeah, any .exe file in the .venv/bin/ directory would be generated by the Python process.

The venv's pip.exe is generated and thus, unsigned. However, Python.exe in the venv is copied, and signed by pup.

Are you sure about that? I would have assumed even the python.exe file was generated during the venv creation. I had a quick look at my bootcamp filesystem, and I have one venv with a python.exe that doesn't match the original python.exe file used to create it (although I think this specific virtual environment was created with the venv module, not with virtualenv).

@ojtest6 has AppLocker never complained about the python.exe file inside %OSDRIVE%\USERS_Username_\AppData\Local\Python\Mu\Mu_VENV-38-(Timestamp)\Scripts\ ? or could you check if that file also doesn't have a digital signature?

---

Edit: Ah, I see Tiago has asked the same question in #2522 (reply in thread)

[tmontes]

Are you sure about that? I would have assumed even the python.exe file was generated during the venv creation. I had a quick look at my bootcamp filesystem, and I have one venv with a python.exe that doesn't match the original python.exe file used to create it (although I think this specific virtual environment was created with the venv module, not with virtualenv).

Not 100% sure. Browsed CPython's venv source which does seem to either copy/symlink with no .exe generation code I could find. Then browsed virtualenv source: oh my god, after navigating bazillions of classes with composition/inheritance and whatnot, I could not tell, 100%, that it isn't generating an .exe along the way... But, again, does not seem so.

I find it interesting that your bootcamp filesystem reveals a different python.exe within the venv...

[carlosperate]

@ojtest6 would you be able to try this Windows installer in your environment with AppLocker? It uses a new signature, so it might still have issues as it needs to build reputation, but it'd be good to check if the all the .exe files in this installer are signed correctly (even if the signature is still building reputation).
https://github.com/mu-editor/mu/releases/tag/v1.2.2.alpha.1

[ojtest6]

Hello,

Unfortunately it looks like 1.2.2 also has the same issue.

This is the message from the AppLocker logs:
%OSDRIVE%\USERS\username\APPDATA\LOCAL\PYTHON\MU\MU_VENV-38-20241218-115125\SCRIPTS\PIP.EXE was prevented from running.

If we look at the 'pip.exe' file in the path above, it has no digital signature which is ideally how we would permit this to run.

I can upload a redacted mu.log if that would help?

Thanks.

[tmontes]

Can you please confirm if Python.exe in the parent folder is signed?

That helps identifying the fix that needs to be put in place.

Thanks.

[ojtest6]

Hello,

The Python.exe file in the same location is not digitally signed.
None of the .exe files in the same location are digitally signed.
If relevant, the Python.exe and Pythonw.exe under 'C:\Program Files (x86)\Mu Editor\Python' are also not digitally signed.

AppLocker hasn't complained about the Python.exe file in either location, but that may be because it hasn't reached that 'step' before preventing the execution of 'pip.exe'

Thanks

[tmontes]

Update:

• Booted up a Windows 10 VM I hadn't used in a while.
• Waited for it to do its updates.

Explanation for the difference between base python python.exe and venv's python.exe:

• Say base python is installed under BASE and venv under VENV
• VENV\Scripts\python.exe is indeed different from BASE\python.exe.
  ...but:
• VENV\Scripts\python.exe is the same as BASE\Lib\venv\scripts\nt\python.exe.

WRT to pup-packaged Mu (1.2.0 or earlier):

• The python.exe in the virtual env is indeed signed.
• The pip.exe binary is not.

WRT to 1.2.2 not so sure:

• If the signing process is as thourough as pup's it should be the same.

IF THAT IS THE CASE:

• The fix is in Mu code venv creation: replace pip install ... with python -m pip install ....

PS: Can you confirm these observations, @carlosperate?

[carlosperate]

I won't be able to try this for a couple of days, but everything you mentioned makes sense.

[tmontes]

(more) UPDATE:

• Installed the 1.2.2 MSI linked above.
• The MSI file itself is signed, but neither the BASE\python.exe nor the BASE\Lib\venv\scripts\nt\python.exe files are signed.

...this is consistent with what @ojtest6 reports.

FOR OURSELVES -- TWO FIXES REQUIRED:

• New signing process is not as thourough as pup's -- needs reviewing.
• Mu venv creation code must really use the equivalent of python -m pip install ....

sigh!