5

There are certain folders in Windows 2012 R2\8.1 where the contents are not writable - one example is Program Files\WindowsApps (which stores apps downloaded from the Windows Store). Obviously this is by design - to prevent people from modifying code that should not be end user accessible - but what specific mechanism is it that stops this? As an exercise I tried various means to circumvent it - but even having taken ownership of the directory, given my user full control permission to it and ensured that no read only flags are set - I still get permission denied trying to write a new file to this area. I even tried doing this from a command prompt running as 'System' (via sysinternals psexec) but I get the same error.

I thought for a while this might be something to do with mandatory access control and integrity levels - but it doesn't seem to be because my process is at a high integrity level - and although mandatory access control is on on this directory - it is set to Low. Effective Access says I have full control. Whatever it is is an OS level control though because mounting the filesystem in Linux the files are perfectly writable.

The reason for the question btw is that I am writing a presentation on the security of Windows Store Apps and I know that someone is going to ask me what is stopping end users from going in there and modifying them. Any pointers to specific documentation on this point from MS would be great if anyone has ever seen such a thing (I have looked extensively but can't find anything). Apologies if this question seems a bit client related - but I see it has already been asked on SuperUser a few times and no one seems to know the answer. Many thanks for any help.

2
  • 1
    Windows NT 6.1 and above implements protection of system resources using a number of mechanisms, including Windows Resource Protection Jun 10 '14 at 10:54
  • Many thanks for that - I looked at the link and this seems likely - but I can't find anywhere that definitively gives a list of protected directories - or any flag on the files to indicate whether one is protected or not. Jun 10 '14 at 15:20
4

This is a new security policy that MS has put in place to disallow the modification of core files for certain applications.

Think of it as Apple's sandboxing on iOS. It is there for the following:

  • Stop files from being modified (changing settings / options / values)
  • DRM (part of the windows store uses DRM and this is the folder that has the conf files)
  • SHA / MD5 (to make sure the checkfiles are the same as these are also stored in this folder for the apps)

I will try to dig out the developers paper that I have, which I received from a Microsoft build conference when 8.1 was released.

Although this was further locked down in 8.1, in 8 you are able to take ownership + control by adding the folder to be owned by Administrators and then giving your user full control.

Funnily enough, if you use a non windows 8 drive you can modify these files to your heart's content, although this may then fail the SHA / MD5 check and corrupt anything that may be in that folder.

4
  • Thanks for that. You can still take ownership in 8.1 - but once you have - it won't let you modify any files. If you do (by for example mounting the files in Linux and changing them) - the apps will no longer run. This is good stuff but it would be great if you have the URL for the white paper you have because I can't find any statement from MS on what it is that actually does this (I see it suggested in the comment above that it is WRP which is probable but I can't find a way to establish it for sure). Jun 10 '14 at 15:18
  • The white paper was used in the presentation of the new Development Tools specific for windows 8.1 development. Just searching through my storage server for it :) Jun 11 '14 at 9:11
  • Would be great if you could find it :) Many Thanks Jun 12 '14 at 20:16
  • I'm surprised that even after all this time nobody's figured out any way to disable this.
    – flarn2006
    May 20 '16 at 5:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.