What Is a Mobile Application Containerization, or Wrapper, and Why Must It Die?
Containerization is an alternative for full machine virtualization. You probably have heard of the well-known containerization technology from Docker or Rocket.
In the case of Docker or Rocket, the container communicates directly with the operating system (OS) core without the need to deploy an operating system inside the container. Many containers share the same OS functions, which results in lower performance consumption used by the deployed containers and also the applications installed within these containers.
However, in this article, we want to discuss mobile “containerization,” which is used to isolate the mobile application from the mobile operating system or other applications installed on the same device. This type of “containerization” works in a different way.
Mobile “containers” behave similarly to an adapter pattern - a software design pattern that allows the interface of an existing class to be used as another interface. The container is not a box with an application in it. The original system calls from an application are rewritten to communicate not with the operating system library but a different library created by the container. Now, if you think that it is easy to hijack every application’s system calls that way, you are wrong. There are many applications that are uncontainerizationable. And if so, not every call can be hijacked.
Some apps just can’t be contained. One simple reason is that not all of their system calls can be intercepted.
As you can see, mobile “containerization” is not a real container. It's just an adapter between the application and the operating system, and it’s not even a perfect adapter. Let’s call it a wrapper.
What is a wrapper?
The wrapper is not a complicated thing. It is just another application which has a sole function of controlling other applications in advance. Unfortunately, wrappers usually require remote management via centralized management tools like Mobile Device Management (MDM) or Mobile Application Management (MAM).
We don’t have to tell you that MDM and MAM solutions cost a lot of money. To compound the issue, in many enterprise mobility use cases, MDM and MAM solutions simply don't work.
Then what are the benefits of mobile app wrapping?
Mainly protection of the OS and the user. Android and iOS operating systems limit applications from manipulating with some protected OS settings. For example, it is not possible to send an SMS from a 3rd-party application on iOS. You have to use a built-in app for that. iOS limits this feature, and no application can perform this action without manually confirming each SMS. Because of such a limitation, it is not easy for application developers to build an advanced application management system or peform other higher-level kinds of application manipulation.
Wrappers can do it.
Sometimes wrappers are used to protect an app from other apps installed on the same device. Sometimes they are used for better portability of the wrapped application and make life easier for app developers. It is true that this portability feature is more related to the wrapper than to a wrapped app. The reason is obvious. The wrapper hijacks most of the application’s calls, and it is the wrapper that communicates with the operating system.
The downside of app wrapping
1. As for security, app wrapping is not an option.
Security is not about relying on the security of the wrapper and letting the wrapper hijack the app’s system calls. Every company wants and demands secure apps. They don’t want another flawed application, additional tool to manage the wrapper solution or integration issues. A wrapped app has more demand on resources e.g. data storage, processor performance, etc. which impacts the user experience.
Security has to be integrated into the mobile app and become an inseparable part of the app.
2. But what about risks from other applications?
There is no way that the wrapper can prevent every access method from communicating with the wrapped application.
Attackers can hijack all application’s system calls in the same way the wrapper can. If the device is rooted (jailbreak on iOS), the wrapper can detect this and prevent the application from connecting to application's backend systems. However, it cannot prevent access to the application data already stored on the device.
It is simple. If the application doesn’t encrypt data-in-motion and data-at-rest, the data is vulnerable and available for attackers.
Alternatives to container and wrapper technologies
1. Android and iOS
The newly released functions from Google and Apple factories are probably more useful than wrapping. Both Android and iOS can separate applications or provide advanced control and manipulation features to maintain the security of the application and its data (Android for Work, Apple iOS 8 Enterprise features).
Are you familiar with the term security-by-design?
Why don’t we build a mobile app that doesn’t rely on other applications for security? Why not use a technology that provides ultimate security protection directly within the app and at the same time without impacting the user experience? Do you know how many people own old smartphones that do not have the capability to support advanced security protocols (e.g., TLS 1.2)?
All of us know and agree that we need to build secure mobile apps. However, pressured by the deadline, heavy workload, and lack of security awareness, it’s very tough to design, build and deliver a secure mobile app that has all necessary security measures.
It is time to rethink and retire with app containerization and wrapping.
What is a proper mobile app security technology?
- Gives visibility into who is accessing and using the mobile app and the application backend to detect the bad actors
- Integrates easily with actual mobile app
- Speeds up data transmission
- Shields the mobile application backend systems from any unauthorized access
- Operates with millions of devices
- Meets high availability demands
- Creates secure private network regardless of the technology used for data transfer, endpoint devices
If you don’t know about such a technology, we do.
Learn more about the most comprehensive application technology for mobile apps by visiting our website or contact us and talk to our security specialists.
- Custom Made vs. Off-The-Shelf Mobile Apps – The Issue of Security
- You Can Build Apps for the Apple TV, But Do You Know How to Do It Securely?
- We Know Why 85% of Mobile Apps Suck in Security. Do You?
- 7 Reasons Why Testing the Security of Mobile Applications Is Crucial for Enterprises
- The Top 5 Mobile Application Security Issues You Need to Address When Developing Mobile Applications
- 5 Security Measures You Need To Know to Ensure the Security of Your Game App
Most Recent Articles
You Might Be Interested in Reading These Articles
Security Researcher Filip Chytry: Online Security Is an Unattractive Topic - until People Get Hacked
I studied at Applied Cybernetics school and worked on various fields: robotics, networks and programming. There I got curious about security and became increasingly passionate about the industry, trying to learn more about cyber crime and attempting to hack into my classmates‘ computers for fun.
Published on August 20, 2015
Distributed Denial of Service (DDoS) is a form of cyberattack which makes the target internet service inaccessible. “Distributed” refers to the fact that the attack comes from multiple sources, to have a bigger impact on the target, as it cannot cope with such a large amount of traffic. In recent years, DDoS attacks have become more and more complex, with many combinations of different attach approaches being used.
Published on February 07, 2017
Mobile app startup companies are notorious for cutting corners. One of the first things that is cut is security. After all, they have the big guys like Comcast, AT&T, and Verizon to protect mobile users, right? Wrong! All the way down the line. TechCrunch's article about security for mobile devices is an interesting theory on the state of security on the Internet. Although, they do hit the mark in the article about how companies fix the problem after the fact of the security breach.
Published on January 13, 2015