Link: https://drive.google.com/open?id=1R0fxJen67quB4dYUEaWZ4DlBctGmi9v_--iWZ2QSj7E&authuser=0
Link: https://drive.google.com/open?id=1ivclLLtaXT1qP7k3AuKEEP4XyVmMf_ucnGTLHBHiayA&authuser=0
Resource Usage Termination Tests
Link: https://drive.google.com/open?id=1R0fxJen67quB4dYUEaWZ4DlBctGmi9v_--iWZ2QSj7E&authuser=0
Link: https://drive.google.com/open?id=1ivclLLtaXT1qP7k3AuKEEP4XyVmMf_ucnGTLHBHiayA&authuser=0
Resource Usage Termination Tests
One of TrUbi's Trust Lease model's goals is to control which other applications are allowed to run simultaneously with our strapps .
In order to do so it is important for us to clearly understand the different types of components an application can have, and also, the many different ways an app can be launched (through those components).
An android application can have four different types of components: Activities, Services, Broadcast Receivers and Content Providers.
We now give a brief analysis over the three most relevant types of components, and explain the different ways to start them, which sometimes leads to application launches.
The figure bellow describes the different components used in the images that describe each component's launch.
Activities are responsible for the user interface, and typically each screen shown to a user is represented by a single Activity component.
Regarding this type of component's initialization, it is important to stress five scenarios:
1) Inside an application, an Activity can trigger the creation of other Activities through the startActivity call (e.g., after a click of a button);
2) Inside an application, a Service can trigger the creation of Activities through the startActivity call (e.g., after receiving a response from an external entity);
3) Inside an application, a Broadcast Receiver can also the creation of Activities through the startActivity call (e.g., after receiving a particular event notification, via broadcast);
4) When we click on an application icon (e.g., on the app menu), we basically trigger the creation of the main Activity of that application;
5) On the other hand, other applications (through any of its components) can launch another application also through the startActivity call, which triggers the creation of other applications' main Activities.
The figure below summarizes these five scenarios.
Services implement functionality of background processes which are invisible to the user.
Regarding this type of component's initialization, it is important to stress four scenarios, many of which are similar to the ones presented for the Activity component:
1) Inside an application, an Activity can trigger the creation of Services either through the starService call or through the bindService call (e.g., after a click of a button);
2) Inside an application, a Service can trigger the creation of other Services either through the starService call or through the bindService call (e.g., after receiving a response from an external entity);
3) Inside an application, a Broadcast Receiver can trigger the creation of Services only through the startService call (e.g., after receiving a particular event notification, via broadcast);
4) On the other hand, other applications can also launch other applications by sending intents that automatically trigger the creation of other applications' Services.
The figure below summarizes these four scenarios.
Broadcast Receivers serve for receiving event notifications from the system and from other applications.
Regarding this type of component's initialization, it is important to stress three scenarios:
1) Inside an application, an Activity can implement its own Broadcast Receiver in order to receive event notifications;
2) Inside an application, a Service can implement its own Broadcast Receiver in order to receive event notifications;
3) On the other hand, other applications can also launch other applications by broadcasting intents that end up being caught by other applications' Broadcast Receivers. Those Receivers can then start other application components.
The figure below summarizes these four scenarios.
We now elaborate on how we plan to prevent these components from being launched, particularly the launches which consequently start applications. For each component we also introduce the findings we made while testing our launch stopping mechanisms.
We plan to prevent Activities from being launched using ASM's Start Activity Hook.
Whenever we click on an application icon or use the startActivity method to start an Activity belonging to another application which is currently prohibited from running because of a Trust Lease, we use this Hook to see if the package of the Activity being called is allowed to run, and decide whether that Activity can be launched based on that information.
Findings:
- One of TrUbi's concerns is to manage not only applications and their correspondent components, but also other potential processes and threads an application can launch but are not associated (at the middleware layer) to that same application. The first finding we've made was that this Start Activity hook mechanism doesn't create an application process.
- The second finding is related to this mechanism's result, when the startActivity method is called from other applications. Basically when application A starts an Activity from application B, if the Trust Lease doesn't allow Application B to run, our mechanism prevents the Activity from application B from being launched, but at the same time, it throws a SecurityException which ends up breaking application A (because apps aren't prepared to deal with Security Exceptions). This page's last image summarizes this erratic behavior.
As we do for Activities, we also plan to prevent Services from being launched using ASM's Start Service Hook.
Whenever we use the startService method to start a Service belonging to another application which is currently prohibited from running because of a Trust Lease, we use this Hook to see if the package of the Service being called is allowed to run, and decide whether that Service can be launched based on that information.
Findings:
- We found that this mechanism has a behavior similar to the Activities, i.e., this Start Service hook mechanism doesn't create an application process.
- On the other hand, this mechanism suffers from the same problem has the Start Activity Hook. Basically when application A starts a Service from application B, if the Trust Lease doesn't allow Application B to run, our mechanism prevents the Service from application B from being launched, but at the same time, it throws a SecurityException which ends up breaking application A (because apps aren't prepared to deal with Security Exceptions). This page's last image summarizes this erratic behavior.
Because Broadcast Receivers cannot be started the same way an Activity or Service are (i.e., there is no startBroadcastReceiver), we plan to prevent Broadcast Receivers from being launched using ASM's Send Broadcast Intent Hook.
Whenever some application or even the system broadcasts an intent which targets a Broadcast Receiver belonging to another application which is currently prohibited from running because of a Trust Lease, we use this Hook to see if the package of the Service being called is allowed to run, and decide whether that Intent is allowed to reach its destination (i.e., the Broadcast Receiver) or not based on that information.
Findings:
- Just like the Start Activity and Start Service Hooks, this mechanism doesn't create an application process.
- Contrary to the other two hooks, this one doesn't have any harmful effects on the application that send intents to Broadcast Receivers belonging to applications which are currently prohibited from running because of a Trust Lease.
As we explained, our Start Activity and Start Service Hooks suffer from a problem when launched from other applications.
Although Applications don't directly communicate with the TrUbi Manager Service to start Activities or Services, and at the same time the SecurityException isn't actually launched by The TrUbi Manager Service, the following image summarizes what happens in these particular situations:
