Sunday, 22 April 2018

MSIX - The Newly Crowned King [Part2]

This is the second and final part of the series "MSIX - The New Land Registry System". Let's continue our journey from where we left in Part1; covering rest of the story 
  • Starting with a short introduction to AppX
  • Touch base on AppXUWP and Windows Store issues
  • Move on to The Rebellion phase;
  • The negotiations phase where authorities had to relax strict rules to satisfy rebel's demands; 
  • The Cops (or rather "The Secret Agents" as they kept changing their name Project C / Centennial / Desktop Bridge / Desktop App Converter), 
  • Find out where did the cops fail 
  • Finally, The Rise of MSIX

We will end this blog with my forecast on the newly crowned King - MSIX

There are lots of things to cover in this part so the blog will be a little lengthy. But I'll try to keep it as short as possible (yeah, I don't like lengthy blogs either). For those who want to read these topics in detail, I'll provide relevant links to Microsoft's website. Right, so let's get started with AppX first.



AppX - The Land Registry System

As discussed in Part1, the AppModel research lead to a new format called the AppX. The vision behind this new format was to have a clean and secure container. Later this got adopted for Universal Windows Platform (UWP) apps. The developers were given a set of interfaces to adhere to while writing their code so that new applications could be safely containerized (or packaged) and deployed. The AppX format also provided a better way of isolating the applications which could then be uploaded to the Windows Store. To keep this blog short, I won't be getting into further details here. Please refer to AppXUWP for more details on Microsoft site.

New Constitution - AppX, UWP, Windows Store

AppX, UWP brought in many positive solutions, but in this blog, I am focusing on the pain-points which needed attention. As these were focused on security aspect, there were restrictions on the location where files/registries got stored and the API surface area (number of Windows APIs allowed) was much shorter. Apps were not allowed to create files/regs in admin locations (like C:\ProgramFiles etc.). For API set, the guiding principle was "don't trust any API which Microsoft didn't consider to be safe". Let's compare it with an analogy of a strict ruler. The King banned everyone from living in the city unless he personally knew that the person is good. Which implies that even though people were good, just because the King didn't know them, they weren't allowed. Its like "suspect everyone except few"In the Win32 era, there were thousands of APIs used by applications. This new rule blocked every API unless it has been identified as safe. Thus allowing a minimal subset of the total Win32 API surface area. 

I always tell my team that ambition should be balanced with practicality. Although having such strict rules was good for security; in my view (I might be wrong), this was an over-ambitious attempt, overlooking the practicality of imposing such restrictions on existing apps. One just can't leave behind those tons of old generation business applications which have been running in the production environment for decades. Afterall, that's the bread and butter for customers in the Windows world!

The Rebellion!

How can there be new revolutionary rules without a rebellion? So, let's go back to our "land registry system" analogy which we started in Part1. The old system allowed anyone to build properties anywhere; say the "System32 colony" or "ProgramFiles county". Whereas the new rules marked these paths as "restricted locations" only allowed to the privileged ministers (Operating System components).

The new landlords (newly written applications) followed these rules happily and built their properties outside the "privileged colonies". But how about the MSI era landlords who already built their properties in random places (I mean the old applications which have been installing files/registries everywhere)? They were asked to dismantle their properties and rebuild them in non-privileged areas. AppX and UWP model restricted access to those locations which apps have been using for decades. 
Also, the smaller AppX API Surface area caused issues for old apps as they were not allowed under the new rules.


And they are not just one or two applications. As per officially announced statistics, there are around 16 Million legacy Win32, .NET applications which couldn't be converted to AppX format without massive code change. I covered this topic in my previous blog post "16 Million Reasons to Fail"! These gave rise to the "Rebels" which couldn't be moved to the AppX/UWP format, and they had all the right to revolt since Microsoft themselves recommended developers to use the System32 folder for app-specific DLLs back in 1990's. Imagine that the Government asked you to build a house in a certain area in the past, and now after living there for decades, the new government changed rules and is forcing you to demolish it and rebuild in another area. Isn't that annoying?



The Negotiation Phase - Rules Relaxation

No authority can ignore a revolt by a massive group of 16 million! So, these issues had to be addressed. Hence the King (Microsoft) decided to relax the rules a little. The rule "suspect everyone except few", was changed to "trust everyone except few". The new rules restricted only those APIs which were known to be vulnerable and allowed apps to use all other Win32 APIs. This relaxation transferred the responsibility to application developers to maintain secure code in their apps. Let's see it using our "strict ruler" analogy. Instead of banning all people (all APIs) whom the King didn't know; he allowed everyone except the known criminals (unsafe APIs) and asked the citizens to have extra security to safeguard their properties (responsibility transferred to the developers). Now that sounds like our modern day society where we have to protect our houses with locks, CCTV etc.

Mission Project C - The Cops/Secret Agents

Project C to the rescue! It's like a mission to bridge the gap between old world and the new AppX world. I like calling it "the secret agent" as it had many identities like Project CentennialDesktop Bridge, and Desktop App Converter. This product was built to bring the legacy old applications on to the shiny new AppX format. 

Now, to satisfy the rebel's demands (old apps), Centennial used broader API set when compared to AppX and it had inbuilt redirection mechanism as App-V used (similar to the mail redirection system discussed in 
Part1), but it is reported to be slightly different than App-V. Centennial used a set of kernel filter drivers to track the activities performed by MSI, analyze the captured data (like COM objects etc.), impose redirections and generate the package in AppX format. This converted and sandboxed old Win32 applications in AppContainer, ready for UWP, Windows Store.



The Plan Didn't Work! Where did the Cops Fail?

Centennial eased the restrictions but came with its own limitations. Unlike App-V (which packaged the app in whichever form app was in); Centennial didn't convert the app to AppX if the app had code considered to be unsafe/buggy. 
  • The developers were expected to change the code in such cases. So, apps without actively maintained code base were left behind. 
  • MSIs with complicated custom actions were a pain for Centennial. 
  • It had a limited API surface area too (much less than Win32 API set). 
  • Converted apps could only be used for Windows 10 and didn't support older operating systems like Windows7. So customers had to maintain MSI for older versions and generate AppX for Windows 10. 
  • Windows store was restricted to Win10 too, which was a pain-point for customers. 
  • Lastly, the apps which needed "full trust" were limited to AppContainer and couldn't be ported to other UWP platforms like XBox, Hololens etc. 

Here is a list of known issues.

The Rise of MSIX - The Newly Crowned King!

To tackle all these issues and bring MSI, App-V, AppX together; Microsoft crowned the new King MSIX. People might relate it to "MSI II" or "AppX II". To much extent, it can be seen as an enhanced version of AppX, as it is direct descendent of AppX. But it has got nothing to do with MSI. As of today, there is hardly any information available on MSIX other than the announcement made during Windows Developer Day and the opensource code on Git.

With recent ransomware attacks exploiting old Windows platforms, security is the biggest concern. And legacy MSI era apps are hacker's paradise. So just converting them to bring to latest platforms isn't enough. 
Plus the advancements in containerization proved that namespace isolation is an extremely efficient way for app security. If you want to read through few of these security concerns and solutions, I covered them in my previous blogs on Legacy Apps and Biggest Challenge of Cyber Era.


MSIX Forecast

Although there isn't much information available on MSIX; if I am reading the pulse correctly, I think MSIX will be a superset addressing each of the sectors Microsoft has been launching in past years.


*This forecast shows my speculation and is not related to my employer or Microsoft's views 

I don't want to prolong this blog any further (its already a lengthy read), so I'll cover each of the sectors shown in the above figure in my next post in Crystal Gazing section "MSIX Forecast". Please note that these are purely my personal views on MSIX's future based on past Microsoft initiatives, recent cyber attacks, and other emerging technologies. Stay tuned.


Priya Saxena.

No comments:

Post a comment