Software & Systems

Согласно исследованию [1], в первом квартале 2015 года ОС Android занимает лидирующую позицию на рынке мобильных ОС с долей в 78 %. Такую популярность можно объяснить, с одной стороны, простотой и удобством ее использования, а с другой – надежностью ее системы безопасности, важной частью которой является подсистема привилегий. Эта подсистема достаточно сложна для пользователя [2], хотя и позволяет разграничить доступ приложений к системным ресурсам. Тем не менее, несмотря на кажущееся удобство указанной подсистемы, ей недостает гибкости:

–      отсутствует возможность задания конкретных параметров привилегии;

–      все привилегии задаются статически в момент установки приложения; пользователь должен либо согласиться с предоставлением всех указанных привилегий, либо отказаться от установки приложения полностью;

–      отсутствует возможность однократного получения привилегии в момент ее непосредственного использования.

Необходимость соответствующих доработок была рассмотрена и обоснована в работе [3]. Назовем ОС с этими изменениями модифицированной в противоположность обычной версии, которая не предоставляет указанных возможностей. Проблема внесения соответствующих изменений в ОС не единственная: в настоящее время существует огромное количество приложений (около 1,5 млн приложений на май 2015 года [4]), написанных для версий Android, не поддерживающих указанные функции. В данной работе предложен подход, позволяющий реализовать возможность опциональных разрешений в модифицированной ОС при работе с приложениями, написанными для обычных версий Android.

Модифицированная подсистема привилегий

В наиболее распространенной на данный момент версии ОС (Android 4.4 KitKat) при установке приложения система запрашивает у пользователя список привилегий, которые требуются приложению для его корректной работы (такой же механизм используется в пока еще мало распространенной версии Android 5.0). Пользователь может предоставить приложению все требуемые привилегии или отказаться от установки приложения. Каждая привилегия предоставляет приложению доступ к определенному ресурсу, а именно, к вызову соответствующей API-функции. Схема вызова функции показана на рисунке 1.

Во время работы приложение вызывает нужную функцию с помощью специального объекта Proxy. Объект Proxy при помощи сервисов ядра находит объект Stub, передавая в него упакованные параметры вызова функции, а также идентификатор вызывающего приложения. Функция получает переданные параметры и определяет, имеет ли приложение соответствующую привилегию; если да, то система выполняет заданную функцию и возвращает результат, иначе – выбрасывает исключение типа SecurityException [5]. Исключения такого рода, как правило, не обрабатываются приложениями (поскольку, если приложению требуется данная функция, то соответствующую привилегию необходимо запросить, иначе не нужно вызывать эту функцию) и приводят к аварийному завершению работы программы.

Идея опциональных привилегий состоит в том, что некоторые привилегии из списка могут быть необязательными, то есть пользователь может их предоставить или не предоставить по собственному усмотрению, приложение же установится и будет корректно работать в любом случае. Разработчик приложения определяет, какие из привилегий являются обязательными, а какие опциональными.

Если пользователь предоставил приложению опциональную привилегию, то соответствующий вызов функции выполнится и вернет реальное значение; в противном случае вызов функции выдаст исключение, но в этом случае разработчик должен быть готов к соответствующей его обработке, так как его приложение запрашивало именно опциональную привилегию.

Для корректной работы приложений, разработанных без учета этой возможности, требуется специальный подход, рассмотренный далее (под корректной работой приложения понимается работа приложения в таком виде, в каком она предусмотрена разработчиком, если все требуемые разрешения были предоставлены приложению).

Основной идеей для реализации возможности работы существующих приложений на модифицированной версии Android является доработанный принцип маскировки ресурсов [6], то есть предоставления приложению доступа к фиктивным ресурсам (термин будет пояснен ниже) таким образом, чтобы приложение не имело возможности отличить фиктивность ресурса от запрета на доступ к этому ресурсу. Рассмотрим, как с помощью маскирования ресурсов добиться корректной работы существующих приложений в модифицированной версии ОС Android.

Поддержка опциональных разрешений для существующих приложений

Для поддержки опциональных разрешений используется следующий подход: если требуемое разрешение у приложения отсутствует, то соответствующий ресурс для приложения маскируется, то есть предоставляется фиктивный ресурс. Например, если приложению требуется доступ в сеть Интернет, но пользователь не предоставляет такого разрешения, то для приложения сеть будет недоступна (с ошибкой тайм-аута), как если бы устройство просто не имело доступа к сети. Разработчик приложения обязан обработать такого рода ошибки, и его приложение в этой части будет работать точно так же, как в случае с потерей устройством сети. Аналогичным образом следует поступать и с остальными разрешениями. Рассмотрим данный подход более подробно на нескольких примерах:

–      привилегии на чтение и запись во внутреннюю и внешнюю память;

–      привилегии на получение местоположения, доступ в сеть Интернет и осуществление звонков;

–      привилегии на доступ к контактам и календарям;

–      привилегии на получение идентификационных данных устройства;

–      привилегии на рассылку сообщений другим приложениям и получение таких сообщений.

Для маскирования доступа к памяти необходимо выделить соответствующую папку (на внешней или внутренней памяти), которая будет имитировать запрашиваемый ресурс. Например, если речь идет о разрешении на доступ к карте памяти, то следует создать папку ограниченного размера, для которой приложению будет разрешен доступ на запись и чтение. Достаточно создать одну такую папку для привилегии и предоставлять ее каждому приложению, которое имеет маскируемую привилегию. Изначально приложение, для которого имитируется внутренняя память, будет «видеть» пустую карту памяти небольшого размера, затем там могут появиться лишь данные, записанные самим приложением. Остальные приложения не получают доступ к этой папке.

При маскировании привилегии на получение местоположения приложение просто получает уведомление о том, что данная информация в текущий момент времени недоступна (аналогичное уведомление приложение получит в том случае, если связь с навигационными спутниками потеряна). Похожим образом обрабатывается маскирование привилегии на доступ к сети Интернет и осуществление звонков – приложение получает уведомление о недоступности сети.

Для хранения данных календарей, контактов и коротких текстовых сообщений (SMS) в Android используется БД [7]. Для маскирования соответствующих разрешений добавляется новая БД такой же структуры, изначально пустая. Каждое приложение, для которого маскируется ресурс, получает такой же доступ к этой БД, какой имело бы в обычной версии ОС к основной БД. Такой дубликат основной БД неотличим для приложения и недоступен пользователю.

Идентификационные данные устройства представляются в виде 64-битной шестнадцатеричной константы [8], которая генерируется при первом запуске устройства и остается неизменной. Для маскирования соответствующей привилегии генерируется еще одна константа, которая и возвращается приложению в случае маскирования.

Для коммуникации между приложениями используются широковещательные сообщения (Intent) [9]. В случае маскирования привилегии получения таких сообщений приложение никогда их не получает, а в случае маскирования привилегии на рассылку таких сообщений сообщения не отсылаются. Аналогичная ситуация возникает в случае, если для данного типа сообщений в системе не зарегистрирован ни один получатель или отправитель соответственно. Подобная ситуация вполне нормальна и обычно означает отсутствие приложений, которые могут посылать или получать такие сообщения.

Таким образом, для каждой привилегии, предоставляющей доступ к некоторому ресурсу, создается еще одна привилегия, предоставляющая доступ к фиктивному ресурсу. Приложение, для которого маскируется привилегия, получает привилегию на доступ к фиктивному ресурсу. При вызове API-функции ОС проверяет, имеет ли приложение соответствующую привилегию. Если да, то работа идет обычным образом. Если нет, то проверяется, имеется ли у приложения фиктивная привилегия. В случае наличия фиктивной привилегии предоставляется фиктивный ресурс, иначе – выдается исключение SecurityException (последний вариант возможен лишь в случае каких-либо непредвиденных ошибок в системе).

Несколько иначе обрабатываются разрешения, связанные с доступом в сеть Интернет [10]. Иной подход необходим потому, что доступ к сети возможен с помощью не только API-функций Andro­id, но и ядра Linux, на котором работает Android. В Android ОС каждому устанавливаемому приложению присваивается уникальный идентификатор пользователя (userid в терминах Unix). Таким образом, для каждого приложения создается отдельный пользователь.

В обычной версии Android при запуске приложения его идентификатор добавляется в Unix-группу, которой разрешен доступ к сети Интернет; ядро Linux модифицируется таким образом, что проверяет, состоит ли процесс, запрашивающий доступ к сети, в Unix-группе inet. В модифицированной версии в случае, если привилегия маскируется, приложение добавляется в группу mock_inet и не получает доступа к сети с ошибкой тайм-аута.

В заключение отметим, что предлагаемые авторами модифицированная подсистема привилегий и метод маскирования привилегий в ОС Android позволяют использовать огромное количество уже написанных приложений без каких-либо изменений в них, не теряя контроля над правами приложения. Пользователь может сам определить, какие привилегии необходимы ему для работы, запретив использование других ресурсов. Действуя таким образом, пользователь может отключить дополнительные возможности приложения, оставив лишь те, которые ему действительно необходимы.

Данный подход позволяет повысить безопасность установки приложений в случаях, когда не ясно, для чего приложение требует ту или иную привилегию, предотвращая таким образом нежелательную утечку данных и другие угрозы. Кроме того, предложенный подход обеспечивает дополнительную защиту от вредоносного ПО, замаскированного под легитимные приложения: можно отключить все потенциально опасные функции приложения путем маскирования привилегий и затем, убедившись в том, что приложение работает именно так, как описывает его автор, включить эти функции, в противном случае пользователь может просто удалить приложение.

  Литература  

1.     International Data Corporation. URL: http://www.idc.com/ (дата обращения: 25.05.2015).

2.     Adrienne P.F., Elizabeth H., Serge E., Ariel H., Erika C., David W. Android Permissions: User Attention, Comprehension, and Behavior. Proc. 8th Symposium on Usable Privacy and Security Washington, DC, USA, 2012, article 3.

3.     Новик А.К. Расширение возможностей подсистемы привилегий Android // XXI Междунар. науч.-технич. конф.: сб. тр. М., 2013. Т. 2. С. 39–44.

4.     AppBrain: Number of Android applications. URL: http://www.appbrain.com/stats/number-of-android-apps (дата обращения: 25.05.2015).

5.     Android Permissions. URL: http://developer.android.com/ guide/topics/security/permissions.html (дата обращения: 25.05.2015).

6.     Beresford A., Rice A., Skehin N. MockDroid: trading privacy for application functionality on smartphones. Proc. 12th Workshop on Mobile Computing Systems and Applications, NY, USA, 2011, pp. 49–54.

7.     Android Content Providers. URL: http://developer.android. com/guide/topics/providers/content-providers.html (дата обращения: 25.05.2015).

8.     Identifying App Installations. URL: http://android-develo­pers.blogspot.ru/2011/03/identifying-app-installations.html (дата обращения: 25.05.2015).

9.     Android Intent. URL: http://developer.android.com/guide/ components/intents-filters.html (дата обращения: 25.05.2015).

10.  Adrienne P.F., Erika C., Steve H., Dawn S., David W. An­droid Permissions Demystified. Proc. 18th ACM conf. on Computer and communications security, NY, USA, 2011, pp. 627–638.