Confirmed users, Bureaucrats and Sysops emeriti
2,974
edits
(→Major) |
|||
Line 179: | Line 179: | ||
We shall limit the rest of the analysis to Copper and to IE because they are the closest to our scenario, but most of that follows will also apply to html5 or C# metro apps as well. | We shall limit the rest of the analysis to Copper and to IE because they are the closest to our scenario, but most of that follows will also apply to html5 or C# metro apps as well. | ||
As it can be seen in the integrity column, all metro apps except IE10 (and its child) run in the AppContainer integrity level which is new to | As it can be seen in the integrity column, all metro apps except IE10 (and its child) run in the AppContainer integrity level which is new to Windows 8. Very little is known about it except that it is engraved in the process token itself. As a medium integrity process, IE10 can do anything it pleases and it does not require the broker to do file access. For example, If the broker <2784> is terminated, one can still use IE10 without a problem. However, When Copper, running at AppContainer integrity, tries to save the process in the current level it crashes. Upon restarting Copper, the broker was automatically launched again. | ||
Another difference is that named kernel objects of an AppContainer process are in a different namespace. For example, in this case the regular 'interactive user' session is session 3 so a regular named object 'Foo' from a traditional desktop application will be "\Sessions\3\BaseNamedObjects\Foo" which is what we see for IE10, while for metro apps it would be: | Another difference is that named kernel objects of an AppContainer process are in a different namespace. For example, in this case the regular 'interactive user' session is session 3 so a regular named object 'Foo' from a traditional desktop application will be "\Sessions\3\BaseNamedObjects\Foo" which is what we see for IE10, while for metro apps it would be: |