Windows Tip Sheet
.NET Security Woes
Network executables and DLLs must enter .NET Framework's zones of trust for them to work right.
Having just written an application (the new Windows-based ScriptVault client
on
www.ScriptingAnswers.com
)
in VB.NET, I ran smack into some annoying behaviors of the .NET Framework. Annoying,
but secure, so it’s worth understanding how the .NET Framework is set
up to help protect you and your users from malicious code.
The problem was this: When users copied my application’s executable to
their My Documents folder, it wouldn’t run. Copied to their Desktop folder,
however, it ran fine. Whaaaat? It turns out, however, that their My Documents
folder was redirected to a network drive, so the .NET Framework saw the executable
coming from the less-trusted “Intranet Zone” on the Desktop; when
the executable was in the more-trusted “Local Zone,” it ran fine.
When in My Documents, the application would just crash with an exception that
had nothing to do with my code and was less than specific about what the actual
problem was.
A good way to figure this out is to open the .NET Framework Configuration console.
Right-click “Runtime Security Policy” and select “Evaluate
Assembly.” Browse to the executable or DLL you’re concerned about,
and select “View permissions granted to the assembly” and click
Next. If your results are anything but “Unrestricted,” you’ll
be able to see where the restrictions are coming from and act accordingly. Assemblies
must at least have “Execute” permissions in order to run, and applications
with a GUI need appropriate permissions to utilize the Windows UI. Additional
permissions can restrict disk, Internet, registry, Active Directory and other
permissions; applications that unexpectedly crash may be trying to perform an
operation (like saving user preferences to the registry) which is restricted
by a .NET security policy.
More Resources
- Read more about the configuration console here.
- Learn to explicitly trust an assembly here.
Micro-Tips
Different versions of Windows and the .NET Framework have different default
values. I say, forget ‘em: Deploy your own policy, instead. Use the .NET
Framework Configuration console to create your own policy and deploy it via
Group Policy, so that your .NET execution security will be fully under your
control.
About the Author
Don Jones has more than a decade of professional experience in the IT industry. He's the author of more than 30 IT books, including Windows PowerShell: TFM; VBScript, WMI, and ADSI Unleashed; Managing Windows with VBScript and WMI; and many more. He's a top-rated and in-demand speaker at conferences such as Microsoft TechEd and TechMentor, and writes the monthly Windows PowerShell column for Microsoft TechNet Magazine. Don is a multiple-year recipient of Microsoft's "Most Valuable Professional" (MVP) Award with a specialization in Windows PowerShell. Don's broad IT experience includes work in the financial, telecommunications, software, manufacturing, consulting, training, and retail industries and he's one of the rare IT professionals who can not only "cross the line" between administration and software development, but also between IT workers and IT management.