Elevation Required to View Crash Dumps

Question

Hi,
Experienced some difficulty configuring the security options for the WER crash dumps folder.
Following on from this thread, it turns out that the folder containing the crash report for a process run at high elevation can only be accessed by another entity with equivalent elevation. From memory, this has not been entirely the case in previous editions of Windows, no doubt because it was adjudged that once a process has ceased execution, elevation was not considered to play a role in accessing the program's logs, or other historical data.
There is, no doubt, good reasons for access to the crash dumps to be at this same elevation level, which can cause a little inconvenience to those who choose to run common programs like Notepad++ and (hence any launched) AutoHotkey scripts at Admin level. In my case, this has almost become force of habit, unfortunately, no doubt due to the scripts querying registry data or having hotkey functionality.
These programs rarely crash, but when they do, one can switch to their WER shortcuts in order quickly ascertain the nature of the problem. UAC won't allow that, and changing the settings in the folder properties security tab is futile.
In this day and age, an intelligent system would "learn" from metrics gathered from the usage of these programs, and in the case of segfault/crash analysis, be somewhat more accommodating. One could imagine that would have played an integral part in the conception of Dr. Watson.
Failing that, a group policy setting (or equivalent registry entries for Home Edition) could easily enable access to the protected WER folders. Is there a good reason not to consider it in future editions of Windows?
Thanks.

Answer 1

As we discussed in the comments posted in unable-to-display-current-owner.html what you are experiencing is the result of two Windows security mechanism. First, the security descriptor for the WER folder does not contain an ACE that allows access to a standard user account. And what also needs to be considered is that the WER folder is also protected by Mandatory Integrity Control. Note that MIC operates in addition to the checks of a security descriptor permissions.

When UAC is enabled a member of the Administrators group is logged on with a filtered token. This token has had Administrator privileges removed from it, has a medium integrity label and related processes run at the medium integrity level. Standard user accounts also run at medium integrity level. When a member of the Administrators group elevates using "run as administrator" then the token associated with the resultant process contains full administrator privileges, a high integrity label and the process runs at the high integrity level.

A security descriptor for a WER folder similar to your situation looks like this when viewed with explorer's security tab advanced dialog -

Note that both security mechanisms are in effect. The security descriptor does not allow access by any standard user or the account of a member of the Administrators group without elevation.

The security dialogs can be used to add an account to the WER folder's ACL and the results look like this -

Note that although the principal has been added to the WER folder's ACL the folder's integrity level HAS NOT CHANGED. Consequently, Mandatory Integrity Control will deny access to the high integrity WER folder from a medium integrity process. The notepad workaround discussed in the comments is effective because elevating notepad creates a high integrity process that is allowed by the integrity checks. Explorer ordinarily runs at a medium integrity level and, unlike old versions of windows, is resistant to elevation (e.g., "run as administrator").

So adding a principal to the WER folder's ACL is not sufficient. The next option is to change the integrity level of the WER folder so that the integrity checking is satisfied by a medium integrity (i.e., unelevated ) process and the control is provided by checking of the security descriptor's ACL. You can accomplish this by running icacls from an elevated command prompt to change the integrity level of the WER folder using the /setintegritylevel parameter.

An example resulting from icacls usage to lower the WER folder integrity level to medium looks like this -

User RLWA32 is now able to access the WER folder and its contents through explore without elevation.