Mobility Extensions (MX) 3.0 - White Paper
March 19th, 2013
Author: George DellaRatta
In order to provide features above the standard Jellybean Android offerings for enterprise customers, three user facing features have been added to Motorola Solutions Android products: Multiuser, Application Lock and Secure Storage.
The Android OS is designed to be used by only one person. The use case is simply a personal device owned by the user. For enterprise customers, this is not the case. A single device may be shared among many different users. The Multiuser feature provides the framework to authenticate and identify the current user of the device.
Upon a resume, the user will be presented with a credentials dialog. The user would need to enter their username and password and log on to get to the standard Android desktop. The credentials dialog replaces the well known swipe key guard which users have become accustomed. Once logged into the device, the user experience is the same as standard Android.
When the terminal times out, the display will go dark. When the power button is pressed to wake the device, the user is again presented with the credentials dialog. If a user has already been logged in, that user’s name is pre-populated in the user name field and the user would need to enter their password to get back to the desktop. If a new user needs to be logged in, this credentials dialog box has a “logout” button to log out the current user.
A Multiuser notifier application will display information regarding the multiuser feature to the user through the status bar and notification window. Upon log in, the status bar will show the successful login animation (green check mark blinks) along with the message “<user> Logged In.” Once the animation times out, the status bar will show the multiuser icon as an indicator that the feature is enabled. Opening the notification window will show the currently logged in user and the state of the data separation feature (see ).
Open the notification window and tap on the multiuser notification. The logout dialog box will be displayed asking the current user if they wish to log out. Tapping “Logout” will force closed all open applications and present the user with the login credentials dialog. Tapping “Cancel” will return the user to the previous window.
When the user hits the log in button after entering their username and password, their credentials are authenticated. If local authentication is selected, then an internal database is used to validate the credentials. If remote authentication is selected, then the credentials are sent to an active directory server for validation.
Local authentication is the default setting for the multiuser feature.
Administrator vs. non-administrator
The multiuser feature utilizes the concept of an administrative user. A user identified as an administrator has permissions to make changes to the configuration settings of the terminal. If any of the administrator utilities are installed in the device, only a user identified as an administrator will be allowed to configure any of the enterprise features. Also, the system settings application will display a reduced settings list for non-administrators. To be specific, non-admins are allowed to select only display, sounds and about menu items.
In this version of the enterprise features an administrator is identified in the local database only. So, if remote authentication is selected, be sure to install at least one administrator into the local database to allow for changes to configuration settings.
When a user logs out, all of the open applications are forced closed. This is done to insure that any private data or applications are not visible to the next user upon log in. In some cases, applications need to span across users. Applications in this category are included on the protected list which is checked before applications are forced closed upon log out.
The multiuser feature also provides a setting to “sandbox” user data. When enabled each user will be provided their own data area in flash which is protected from all other users. Applications on the protected list, since they span users, are exempt from data separation. Also, the SD Card is considered a public data area and is also exempt from data separation.
NOTE: it is recommended that the terminal be rebooted when the data separation setting is changed to insure that all of the application’s data pointers are looking in the correct locations.
In the unmanaged environment, an administrator for the system of devices needs to create the user database which can be imported to the device.
The Enterprise Administrator is a desktop application specifically designed to allow administrators manage the usernames and passwords of the users of devices.
The “passwd” file must be copied to an SD Card and the SD Card placed into the terminal to be configured.
An Android APK called Multiuser Administrator must be installed on the device to be configured. Upon launching the Multiuser Administrator, the user will be presented with four options. The first step in configuring is to install the credentials. Pressing this button will cause the utility to open the “passwd” file from the root of the SD Card and read each user specified and populate the local database with each user’s parameters. Once completed, pressing the enable button will enable the Simplified Multiuser feature.
Powering off the device and then back on again will present the user with the credentials dialog. Once enabled, only users identified as administrators will be able to use the MultiUser Administrator to re-install users, disable the feature or capture the log.
The Application Lock feature along with MultiUser provides a white list of permitted applications for groups of users. Each user will belong to a group and each group will have their own white list. Applications not on the permitted list cannot be executed or installed.
In combination with the MultiUser feature, users are assigned to groups and each group will have its own white list of permitted applications. Only those applications on the white list will be presented as an icon on the applauncher for that user. For example, it user1 is a member of group1 and group1’s white list contains the application with package name com.domain.appname, then that application will be visible on the applauncher screen when user1 is logged in. Also, if user2 is a member of group2 and the same application’s package name is NOT on group2’s white list, then that application will not be visible on the applauncher screen when user2 is logged in. More importantly, any application not part of the user’s group’s white list cannot be launched from any method other than as a service from a permitted application.
Application Lock also extends to the installation of applications. Only applications with package names included on the user’s group’s white list can be installed.
Configuring Application Lock
In the unmanaged environment a text file listing each of the groups and the users for each group must be build. The groups file (named “groups”) takes the following format:
Each group has an associated white list of permitted packages. Each white list file is named with the group name and contains one package permitted per line. It takes the form:
<package name #1>
<package name #2>
Let’s use the same users defined above, Alpha, Beta and Gamma. Alpha is an administrator, Beta is a manager and Gamma is a worker. The groups file could be:
Notice that Beta is in two groups. The manager has access to not only special applications for managers, but can also have access to all of the apps specified for workers. If a user is in more than one group, that user’s white list is the total of all applications in all of the corresponding white lists.
The white list files could be:
“Administrators” file contains:
.*“Managers” file contains:
com.domain1.application1“Workers” file contains:
All members of the Workers group has permission to access all of the standard system applications plus the application with the package name com.domain2.application2.
All members of the Managers group has permission to access all of the standard system applications plus the application with the package name com.domain2.application2.
In our example, Gamma fits into the Workers group only and will have permissions to the standard system applications plus that one additional application. Beta, will have permission to not only the application with the package name com.domain1.application1, but also com.domain2.application2.
All members of the Administrators group have permission to any and all applications installed on the device.
The groups file and the white list files can use the ‘#’ to start a line to identify a comment. So, the Administrators file could be:
# This is the administrators file
# Administrators are permitted to any and all applications
The wildcard ‘*’ character will permit any matching package name to be part of the white list. For example, com.motorolasolutions.* in the group’s white list will permit that group to access all packages prefixed with com.motorolasolutions
The groups file along with all of the white list files are then copied to the root of an SD Card. Place the SD Card into the terminal being configured.
An Android APK called AppLock Administrator must be installed on the device being configured. Upon launching the AppLock Administrator, the user will be presented with three options. The first step in configuring is to install the groups and white list files. Pressing this button will cause the utility to open the groups file and populate the database with all of the groups and users. It will then look for a white list for each group and populate the database with each white list. Once completed, pressing the enable button will enable the AppLock feature which takes effect immediately.
Only users identified as administrators will be able to user the AppLock Administrator. Important notes: 1) Users not assigned to any groups will have access to the standard system list only. 2) Users not defined in the MultiUser feature can be assigned to groups without error.
This feature provides a mechanism to secure data being written to an SD Card so that in the event the SD Card is lost or stolen the data remains secure and can only be read by authorized users.
The secure storage feature provides a mechanism to create and mount an encrypted file system for use by an application. The encrypted volume itself may reside on either the SD Card or internal storage and can have a mount point at any permitted location. With the automount feature selected, upon a reset, the volume will be mounted and ready for use without needing any additional steps by the user.
Configuring Secure Storage
In an unmanaged environment, parameters defining the encrypted file system (EFS) need to be imported into individual devices. This is done through the use of the Secure Storage Administrator which allows IT Managers to define the parameters directly or import the parameters from text files deployed from an SD Card. Creation of the EFS is a multistage process beginning with the installation of the encryption keys. A list of the encryption keys and their associated EFS volumes is maintained locally on the device. The key can be installed manually by using the Secure Storage Administrator to enter the key or imported from a file through the same utility. A key is denoted by a name and has an associated value which is used to encrypt and decrypt data being written to the EFS. The utility can also provide a list of key names. (NOTE: there is no API to return the key values) Once the key has been installed, a volume can be created. The parameters defining the volume are: volume name, media holding the volume, the key name used for the volume, the mount point of the EFS, the automount flag and finally the EFS size. The name is the file name to be used as the secure volume on the media specified. In most cases, the media will be “sdcard” The mount point is the location within the device that should be used for this volume to be used. For example, if the secure volume is used by an application that writes to the “appname” folder on the sdcard, then the mount point would be “/mnt/sdcard/appname” The automount flag identifies this volume as one that should be automatically mounted when the system boots. This makes the secure storage feature transparent to the average user. Without this flag set, each user would need to use the Secure Storage Administrator to mount the secure volume as needed. The size of the EFS is described in MB. Once created the EFS can be mounted and used by the system. Additional functionality provided for secure storage is the revocation of encryption keys and the deletion or unmount of EFS.
This utility provides a means of managing users, groups and white lists through a simple user interface which consists of five main screens.
The screen shot below shows the Enterprise Manager home screen. The home screen displays all current items in three separate lists:
Users : System users. Consists of the user’s name, password, enabled status, and admin status
Groups : System groups. Consists of users and packages available to users within each group.
Packages : System packages. Consists of APK package names which can be added to groups.
From here the user can add users, groups, and packages by clicking on the “+” button, delete them using the “-“ button, and edit them using the respective “Edit” button.
The screen shot below shows the Enterprise Administrator user management form for creating new users and editing existing users. From here the user can set the username, password, admin status, and enabled status.
The screen shot below shows the Enterprise Administrator group management form for creating new groups and editing existing groups. From here the user can set which existing users and packages are to be included in the group as well as set the name for the group. The double arrows allow the user to easily move all items from “available” to “in Group” and vice-versa.
The screen shot below shows the Enterprise Administrator package management form for adding new packages and editing existing packages.
Important parameters for the server being used for remote authentication can be set in this dialog.
Once all of the users, groups and white lists have been created, use the export button to create the set of files necessary to be placed into the devices to be configured. Three types of files are created: the passwd file which contains the users and their credentials, the groups file which contains the list of groups and members and the white list files.
The “passwd” file uses the following format:
<username>:<hashed password>:<user id>:<admin status>:<unused>:<unused>:<enabled status>
Where:User id is an integer value which begins at 100. All user ids must be unique per user.
Admin status must be 2000 to identify an administrator and 1000 to identify a non-admin.
The groups file uses the following format:
Any member in more than one group will get the union of the white lists of all the corresponding groups.
The white list file has the same name as the group to which it is assigned and is a list of package names of the applications on that group’s white list.
If remote authentication has been chosen and the server settings have been set, the user can export these setting in a file named “server”, which will contain the settings in the following format:
The file can be found in the directory C:\Users\\AppData\_APP_DATA\.
The user may import a list of users from a credentials or “passwd” file. The credential file uses the following format:
<username>,<plain text password>,<admin status>,<enabled status>
Valid characters for the user name and password fields are all of the uppercase and lowercase letters, all numbers, @, +, - and _. For example, there are 4 people who will be using the device: alpha, beta, gamma and delta. Each user has their user name the same as their password. Alpha is the only administrator and gamma’s account is disabled at this time. The corresponding credentials file would look like:
The “passwd” file that was exported previously can be imported back into the enterprise administrator.
Importing Groups and White Lists
The groups file and white list files that were exported previously can be imported back into the enterprise administrator.
The user can save the work they have done within the Enterprise Administrator. Saving generate a “passwd” file, and a “database” file which contains all group and package information from the users current session. These are the files used when the application starts up to restore the user’s last session. The locations of the saved data files are stored in the “_APP_DATA” folder within the application data directory. (C:\Users\\AppData\_APP_DATA\)
The only generated file unique to the Enterprise manager is the “database” file which stores all group related information when a user saves their work. (Note: User information is stored in the “passwd” file)
The format of the Database file is as follows:
#GROUP_USERSGroup1Name: group1User1Name, group1User2Name…
…#GROUP_APPSGroup1Name: group1App1PkgName, group1App2PkgName…