Android Device Administrator: a BYOD Employee's Perspective

00. Introduction

At Duo Labs, we occasionally get a chance to work on pet projects, unrelated to our main research area. I recently had the occasion to install Outlook on an Android phone. To my surprise, it requests Device Administrator privileges, which would give it elevated control over my device. This motivated an investigation into what that really means for me as a user.

For those who are unfamiliar, Device Administrator applications are the Android-equivalent of Mobile Device Management (MDM) software. Like other MDM software, Device Administrator applications can set policies on usage of the phone. They can enforce password complexity requirements, automatically lock the device, disable installed applications, and even wipe the device, all without any confirmation or approval from the user. Notably, the user must first consent to this level of access, typically during the first use of the app. However, like many things on Android, it's an all-or-nothing situation in which the user will generally be prevented from using the application at all if they do not enable Device Administrator access.

As someone who is conscious of my privacy and personal liberties, I am very hesitant to allow an application controlled by a third party to have such intrusive privileges on a device that contains access to my personal accounts, family photos, and information about all of my friends and family as well. Until just recently, I was under the mistaken impression that, once allowed, a Device Administrator application could call any privileged Device Administrator function, but it turns out that, like the Android permissions system, Device Administrator applications must request access to individual policies to perform many of the most privileged operations.

What follows is an investigation into the murky world of Android Device Administrator privileges.

01. Outlook Privileges

When configuring Device Administrator access for the Outlook application, it displays this list of privileges that it will be granted.

These operations frankly seem pretty innocuous. However, in reviewing the Android developer documentation, one of the first policies highlighted is the ability to wipe the device if an incorrect password is entered more than a configurable number of times. This raises the question, "Can Outlook wipe my device if I fail to unlock my phone?" A screenshot found online from an older version of the Device Administrator policy screen makes it appear so.

I would like to better understand what actions these policies enable, and specifically determine whether the Outlook app can perform any of the following intrusive behaviors:

• Wipe the device, under any circumstances
• Monitor and uninstall other applications on the device
• Retrieve personal (non-enterprise) data
• Change or delete any personal data
• Lock me out of my own device

02. Policies and Device Administrator Functions

In Android applications, privileged operations are protected behind permissions. The device administrator policy screen above looks a lot like a list of permissions granted to the Outlook app.

The Android documentation doesn't immediately make it clear what these privileges are or what permissions they grant, but digging into the developer pages, we can eventually find a list of Device Administrator Policies that defines the following policies as well as a cursory description about what privileges each grants.

These policies also closely map to the Device Admin Policies screen shown to the user above. If the Device Administrator application does not hold a given policy, it will be unable to perform any privileged action requiring that policy.

However, the Android DevicePolicyManager defines 214 new public methods that device administrators may call, many of which perform potentially intrusive actions. And only 22 of these methods require the application to hold one or more of the above policies. To be fair, most of these new functions are generally pretty harmless, such as a large array of get* and is* methods that simply query device state. However, there are still plenty of functions that are potentially quite intrusive, as we’ll dig into in Section 5.

To confirm which policies the Outlook app uses, I pulled and unpacked its APK. From res/xml/outlook_device_admin.xml we can see it uses the following policies:

<?xml version="1.0" encoding="utf-8"?>
<device-admin>
  <uses-policies>
    <encrypted-storage />
    <force-lock />
    <limit-password />
    <watch-login />
  </uses-policies>
</device-admin>

03. Device Owners and Profile Owners

In the parlance of Device Administrators, there is another subtlety that is also poorly documented from an employee perspective. Some of the privileged functions that device administrators may call will return exceptions if the device administrator app is not a "Device Owner" or "Profile Owner", but these terms were not immediately clear to me. So I will attempt to define them here. Both Device Owners and Profile Owners are super-privileged device administrators.

Enterprise apps can create an enterprise context in which to store enterprise user data, segregated from the main (personal) user account on the device. When doing so, they can register themselves as a privileged Profile Owner for that enterprise profile, and gain the ability to perform additional privileged actions on that enterprise data. However, in theory they cannot execute these intrusive functions on the main user profile, as they are not the Profile Owner for the main user profile.

Device Owners are device administrator apps that are privileged to perform these additional intrusive actions (and more!) for the entire device, on any/all device profiles. It is unclear exactly how an application becomes a device owner. The documentation only says this is done during the device provisioning process. Regardless, it does not appear that any application can become a device owner once the device is set up and provisioned, although I could be wrong.

04. What can the Outlook Application do?

There are many actions the device administrator application may take (with appropriate privileges), such as setting a more restrictive password policy. However, to me, this is minimally intrusive since I should really be using a secure login anyway. Instead, let's revisit the list of worrisome behaviors from before.

Wipe the device, under any circumstances?

The three methods that can wipe your device are setMaximumFailedPasswordsForWipe and two wipeData methods. All three of these require the USES_POLICY_WIPE_DATA Policy, which the Outlook app does not request. Consequently, we can conclude that the Outlook app cannot wipe your personal device.

However, other Device Administrator applications that request this policy will be able to do these actions, which I find to be very intrusive on a personal device.

Monitor and uninstall other applications on the device?

It turns out that monitoring the other applications installed on your device can be done with the PackageManager.getInstalledPackages method, a function that exists entirely outside of the device administrator sphere and requires no permissions. So short of rooting, there does not appear to be a way to prevent any application from doing this. However, the more worrysome behavior is the ability to uninstall applications, for which device administrators can do a different, but similar action.

The setPackagesSuspended method, which does not require any special policy, allows the Device Administrator to disable the use of a specified app. However, it does require that the Device Administrator is a Device or Profile Owner. It is unclear from the documentation whether a Profile Owner can suspend applications that it did not install within the context of its profile. There does not appear to be a way for the Device Administrator to actually uninstall an application, which means that if the user disables the Device Administrator application, they will regain use of their previously-disabled app.

The Device Administrator can also re-enable applications that the user has disabled.

Retrieve personal (non-enterprise) data?

There do not appear to be any device administrator methods that provide this capability.

Change or delete any personal data?

clearApplicationUserData does not require any Device Administrator Policies and allows the wiping of user data from installed applications. However, it can only be done by a Profile Owner (and presumably only on the enterprise profile data). Consequently, we do not appear to need to worry about the Outlook app being able to wipe our personal data.

Lock me out of my own device?

The two lockNow methods allow the Device Administrator to lock the device immediately, provided the application requests the force-lock policy. The Outlook app requests this policy, so it appears possible the Outlook app can lock users out of their devices by repeatedly calling these methods. Obviously, we would never expect a well-behaving application to do this. It's a good thing software never misbehaves. Still, this is likely low risk.

Any other (potentially) alarming functions?

addPersistentPreferredActivity does not require any Device Administrator Policies and can set a new default application to handle Intents. The device admin must be a Device or Profile Owner, but again it is unclear whether the Profile Owner can set default Intent-handling applications for Intents generated by personal (main user) applications.

installExistingPackage allows the Device Administrator to install a previously-installed application for which the APK has been held on the device (which it can do with a different method). This requires that the device administrator be a Device or Profile Owner, and presumably installs the application within the enterprise profile context.

installSystemUpdate allows the Device Administrator to install a system update on the device from a file it can specify. Fortunately, this can only be called by a Device Owner. Otherwise, this would be extremely alarming.

There are a number of methods that allow the device admin to set and enforce password complexity requirements, including forcing the user to set a new password. However, the device admin does not get to see the user's password, and these requirements can be reverted by removing the device admin, so I see this as relatively reasonable.

retrieveNetworklogs, retrievePreBootSecurityLogs, and retrieveSecurityLogs allow the device administrator to retrieve a list of sensitive logs. However, they require the admin to be a Device Owner, and so are not applicable in the case of the Outlook app.

setAlwaysOnVpnPackage allows the device administrator to designate a VPN application that will always run and handle network connections for the device. It requires Device or Profile Ownership. It is unclear whether a Profile Owner can set an always-on VPN for the entire device including for applications running in the context of the main user, or whether it will only affect the enterprise context.

There are a large number of other potentially-intrusive methods, but unless otherwise listed here, they seem to reasonably require Device or Profile Ownership and are most likely not intrusive to the main personal use of the device.

05. Verdict on the Outlook App and Device Administration

Due principally to Android heavily restricting almost all intrusive methods to only Device and Profile Owners, that the remainder require the device administrator to explicitly request policies/privileges, and that Outlook does not request the most intrusive policies, the Outlook application appears not to be able to cause any real harm to personal accounts on my device.

While many of the 214 new public methods available to device administrator applications are potentially quite intrusive, the vast majority of intrusive methods are available only to Device and Profile Owners, and consequently can only perform these actions on Enterprise data. The remainder seem to be locked behind Policies (privileges) that are explicitly announced to the user before they designate the application as a Device Administrator. With the lone exception of the USES_POLICY_WIPE_DATA policy, the actions the Device Administrator can take with any other policy seem to be able to be reverted by revoking the device administrator privileges of the application. Android Device Administrator functionality strikes a healthy balance between defending enterprise data security requirements and protecting employee personal privacy.

06. A Comment on BYOD and MDM

The Bring Your Own Device (BYOD) policy is occurring in many organizations, both to cut enterprise costs and because employees don’t want to have to carry both a personal and company device. Many Mobile Device Management (MDM) solutions, in my opinion, grant the enterprise far too much control over what is likely the employee’s primary personal computer.

Even if installation of the company’s MDM is technically optional, an employee who opts out may be unable to get notifications for important emails or meeting reminders, one of the most basic business functions in the modern world. Because it is made incredibly inconvenient not to, employees may find themselves coerced into installing the Device Administrator application. Even if employees are dissatisfied, it is likely that very few will vocally raise the issue if they feel the policy is outside their power to change.

From the enterprise perspective, it is a particularly difficult problem. Providing a dedicated company device (plus data plan) for each employee is a huge expense, and many employees don’t want to carry around two devices in any case. The enterprise has a right to make sure its data is protected, and so BYOD is only tenable if the enterprise has assurances that the device is secure, perhaps including wiping if the device is lost or stolen. In some industries, such as healthcare, this may not simply be a company requirement, but a federal regulation as well.

However, it appears that Android has built a platform that can segregate and protect employee data while still respecting employee privacy and autonomy. My only recommendation would be for them to please clarify their documentation, from the perspective of a concerned employee, around the precise extent each device administrator function has the potential to affect personal data.

07. Outlook and Regular Android Permissions

While the additional privileged capabilities the device administrator policies grant the Outlook app seem reasonable to me, it is entirely separate from the powerful permissions the Outlook app requests as a regular Android app. Luckily, in recent versions of Android, we finally have a way to selectively restrict much of a user's personal data, such as SMS and contact information, from applications that request (demand) those permissions.

The full list of permissions the Outlook app requests can be found here:

android.permission.INTERNET
android.permission.WRITE_EXTERNAL_STORAGE
android.permission.ACCESS_NETWORK_STATE
android.permission.VIBRATE
android.permission.GET_ACCOUNTS
android.permission.READ_PROFILE
android.permission.READ_CONTACTS
android.permission.READ_CALENDAR
android.permission.WRITE_CALENDAR
android.permission.MANAGE_ACCOUNTS
android.permission.AUTHENTICATE_ACCOUNTS
android.permission.READ_SYNC_SETTINGS
android.permission.WRITE_SYNC_SETTINGS
android.permission.READ_SYNC_STATS
android.permission.WRITE_CONTACTS
android.permission.ACCESS_FINE_LOCATION
android.permission.WAKE_LOCK
android.permission.CAMERA
android.permission.REORDER_TASKS
android.permission.RECEIVE_BOOT_COMPLETED
android.permission.READ_EXTERNAL_STORAGE
android.permission.USE_CREDENTIALS
android.permission.READ_APP_BADGE
android.permission.FOREGROUND_SERVICE
com.samsung.accessory.permission.ACCESSORY_FRAMEWORK
com.samsung.android.providers.context.permission.WRITE_USE_APP_FEATURE_SURVEY
com.samsung.WATCH_APP_TYPE.Companion
com.microsoft.office.outlook.ACCOUNT_CREATION_PERMISSION
com.google.android.c2dm.permission.RECEIVE
com.google.android.finsky.permission.BIND_GET_INSTALL_REFERRER_SERVICE
com.sec.android.provider.badge.permission.READ
com.sec.android.provider.badge.permission.WRITE
com.htc.launcher.permission.READ_SETTINGS
com.htc.launcher.permission.UPDATE_SHORTCUT
com.sonyericsson.home.permission.BROADCAST_BADGE
com.sonymobile.home.permission.PROVIDER_INSERT_BADGE
com.anddoes.launcher.permission.UPDATE_COUNT
com.majeur.launcher.permission.UPDATE_BADGE
com.huawei.android.launcher.permission.CHANGE_BADGE
com.huawei.android.launcher.permission.READ_SETTINGS
com.huawei.android.launcher.permission.WRITE_SETTINGS
com.oppo.launcher.permission.READ_SETTINGS
com.oppo.launcher.permission.WRITE_SETTINGS
me.everything.badger.permission.BADGE_COUNT_READ
me.everything.badger.permission.BADGE_COUNT_WRITE
com.google.android.gms.permission.ACTIVITY_RECOGNITION