Package.Open Requested registry access is not allowed

Question

We are calling System.IO.Packaging.Package.Open() in an ASP.NET application. Further, a Windows impersonation has been performed before calling this because the package to be opened is stored in a secure location and the impersonation is required in order to read it.

The problem is that Package.Open() calls EventTrace.EasyTraceEvent() which in turn calls MS.Utility.EventTrace.IsClassicETWRegistryEnabled() which throws a security exception of Requested registry access is not allowed.

This occurs even if is specifically disabled in Web.config . In both Debug and Release mode.

Thus my dilemma. The impersonation is required because the file (package) is stored such that it is only accessible by the impersonated account. Copying it to an insecure location would defeat the purpose of the security.

Granting the impersonated account access to the registry opens a security hole in the other direction. This account does not have nor otherwise need any access to any other system resources beyond a specific set of files and folders.

What I really want is for EventTrace to take a flying leap off a cliff, but I don't know how to tell it to do that.

Any ideas?

Pashto

Answer 1

Short answer: Use a stream. Do impersonation to open the stream, end the impersonation, and then pass the still-open stream to Package.Open().

Long answer:

• The source of the error is the static class initializer for EventTrace. It calls IsClassicETWRegistryEnabled() which in turn accesses the registry. Since it is in the class initializer it means that there is no way to disable it and that EventTrace is fundamentally broken when it comes to Impersonation.

• Package.Open() is really a wrapper around "new ZipPackage()".

• ZipPackage is a sealed implementation of the Package abstract class.

• ZipPackage has no public constructors.

• ZipPackage in turn uses internal methods on ZipArchive which is in the MS.Internal.IO.Zip namespace and is also a sealed class.

Conclusions:

• System.IO.Packaging has issues with Impersonation when that impersonation doesn't have sufficient registry access.

• System.IO.Packaging should be looked at as a private Microsoft namespace, not a public one.

Options:

• Move the file out of a secure area so that impersonation is not necessary.

• Load the file when impersonation is not necessary and store the data some other way (ex: in a DB)).

• Open a stream under impersonation, end the impersonation, and then use Package.Open() on the stream.

If anyone is curious the packages we are reading are Visio 2013 VSDX files.

Pashto

Answer 2

I looked through the .NET source reference, and the key that it needs access to is HKEY_CURRENT_USER\Software\Microsoft\Avalon.Graphics. Granting "Everyone" read access on that specific key has no security implications that I can think of, and solves the problem.

Rehnberg

The reason for this is that even though application is impersonating user B, access to the registry uses user A (the one that started the app). Hence, you are trying to access HKCU of user A with user B. – Gape

This worked for me with a similar issue with OpenXML. I went through each HKEY User registry setting and granted Authenticated Users read on HU\{SID}\Software\Microsoft\Avalon.Graphics. The HKEY_CURRENT_USER registry is the registry for the account that is logged in at the time. HKEY_USER\{SID} is where the HKCU registry settings are stored for other accounts that have logged into the system. – Habited

Answer 3

Next time I come here to solve this problem I just want to remind me that:

Add the application pool account as local admin. The effect is that is has the permission to read the registry for all users that get impersonated.

If that is not a option, then you need to RevertToSelf before making the call. The effect is that it stops impersonating so it now only needs permission to read the registry of the current user, which is itself.

Branchia