0

Background (simplified)

I use continuous integration and deployment on my production servers. For example, I have an application which monitors Team City and deploys built packages to IIS automatically.

For this code (which we write), I want to guard against (or make more difficult for) a man in the middle modifying assemblies on their way to the production servers. If someone succeeded in changing the assemblies (either in transit or locally on the machine) I want to guard against (or make it more difficult for) those assemblies being executed.

We already employ a whole raft of security measures to protect against this kind of thing (eg Agents which monitor critical file hashes to make sure they haven't changed, auditing, minimal user rights and so on).

We want to increase our push cadence, but the third party software we use to monitor file hashes is, lets say, "cumbersome to update".

Question

Assume that I trust the OS (including the .net CLR). I'm wondering if I can lever the code signing security build into the CLR. In a similar way to how PowerShell doesn't let you run unsigned powershell scripts perhaps.

Is it possible to do this, ie to configure the CLR to only run signed assemblies from a whitelisted set of public keys?

Please let me know if this is a bad idea!

Daniel James Bryars
  • 4,429
  • 3
  • 39
  • 57
  • 1
    What's your threat model? What can an attacker do in a hypothetical case? Can't you just transfer the deployment artifacts over a secure channel? I mean you must have something in place already. – usr Jan 24 '15 at 17:04
  • Yes I already transfer the deployment artefacts over a secure channel. We already check that that the certificate is trusted. I'm always trying to think of ways to improve security. Given the things we already do this vector is not likely to be easily exploitable. But if the cost of implementing signed packages is low I'd be very interested in doing it. – Daniel James Bryars Jan 27 '15 at 11:59

0 Answers0