How can code signing posibly be secure on Windows when signed executables act on unsigned input?

Question

As a security measure, my Windows-based work computer has been configured to deny any application that hasn't been signed with a valid certificate; my system will run a signed executable from DropBox's website, but it will refuse to run an unsigned open-source executable instead prompting me to enter an administrator password.

This behavior matches my mental model of how a security measure such as this would work.. except that it breaks when for interpreters like python.

When I downloaded python on my computer, I was able to successfully install it thanks to it being signed by a valid certificate. I was also able to run an arbitrary script I copied from another system because the interpreter is signed. In other words I was able to run an unsigned program (script) on a system that I thought was configured not to!

So given the facts that a) users can download signed programs, and that b) those programs can act on unsigned input:

1. Is this really how the code signing and verification system is intended to work on Windows?
2. If so, wouldn't a malicious actor be able to bundle any signed interpreter along with their own malicious script and have their code run on any Windows system?
3. If so, what purpose does this system serve?

I admit that I likely may be missing something here, given a hole as large as this couldn't have been missed my Microsoft. Perhaps my work computer is misconfigured somehow, or that I made a mistake somewhere in my analysis. Please have the patience to correct me if I have.

Answer 1

So given that users can download signed programs, and that those programs can act on unsigned input

This statement is not only true for things like Python, but also for a word processor, a spreadsheet, a PDF reader, a web browser etc. All these process unsigned input (user entering text, opening existing documents) and often even unsigned programs (like calculations, Javascript, ...).

If so, wouldn't a malicious actor be able to bundle any signed interpreter along with their own malicious script and have their code run on any Windows system?

Correct. Or just use signed software already available on the system, like a web browser. This is actually done with attached HTML files in mails, attached word documents, PDF etc.

If so, what purpose does this system serve?

Reduce the risk, not eliminate it.

It is up to the signed program to implement additional protections. Browsers usually run code within a sandbox. Other applications have only a limited set of functions what user input can do. Some languages like Powershell can be configured to only allow signed scripts.

Note that just because an application is signed does not mean it is fully safe to use. Even signed programs can do harmful things, either inadvertently or by design. Similar to the certificates of a website a valid signature proves only who created the application and says nothing about the actual security.

It is still up to the administrator of the system to decide which programs to trust. Trusting any kind of program is worse than trusting only signed programs, but trusting only signed programs from some trusted vendors is even better. Or ultimately only whitelisting a set of verified programs.

Answer 2

Your points are valid. It does not make much sense to sign a program like a Python interpreter that runs unsigned code, or to sign any program that loads untrusted DLLs.

However, it does make a lot of sense to sign the installers for these programs that you download from the Internet. The installers can in theory be written to not execute any untrusted code, and I think this is what the installer frameworks try to do. The installer contains all the files it will extract and store on your computer, so a single digital signature on the installer binary verifies that those files have not been tampered with after the installer was created.