BC/NW 2013, №2 (23):11.3

РАСШИРЕНИЕ ВОЗМОЖНОСТЕЙ ПОДСИСТЕМЫ ПРИВИЛЕГИЙ ANDROID

Новик А. К.

(ФГБОУ ВПО «Национальный исследовательский университет «МЭИ», Москва, Россия)

Введение

Согласно исследованию известной компании International Data Corporation [1], в первом квартале 2013 года операционная система Android занимает лидирующую позицию на рынке мобильных операционных систем с долей в 75%. Такую популярность можно объяснить, с одной стороны, простотой и удобством ее использования, а с другой — надежностью ее системы безопасности, частью которой является подсистема привилегий.  Тем не менее, несмотря на кажущееся удобство указанной подсистемы, ей недостает гибкости:

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

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

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

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

Подсистема привилегий со стороны пользователя

При установке приложения в системе Android пользователю предлагается список разрешений на доступ к потенциально опасным ресурсам, таким как доступ к сети Интернет, чтение сообщений электронной почты и т.д. На рисунке 1 показан пример такого списка разрешений, запрашиваемых почтовой программой.

Рис. 1. Список разрешений, запрашиваемых приложением

Пользователь может предоставить приложению все привилегии из списка или отказаться от установки приложения. В предложенном примере приложение запрашивает, в числе прочего, разрешение на доступ к сети Интернет и возможность читать и изменять список контактов. Таким образом, программа может как использовать список контактов для отправки почтовых сообщений, так и пересылать список контактов злоумышленнику, например, для создания базы адресов для дальнейшей рассылки по этим адресам сообщений, содержащих спам. Очевидно, что если это приложение — клиент электронной почты, то можно ограничить привилегию доступа к сети Интернет конкретным адресом почтового сервера, с которым предполагается работа. Кроме того, порты для связи с почтовыми серверами обычно отличаются от портов, используемых для, например, взаимодействия с веб-сайтами (993 и 465 обычно используются почтовыми серверами, а 8080 — для веб-сайтов).  Ограничивая подобным образом привилегии приложения, разработчик увеличивает степень доверия к своему приложению. Действительно, даже если приложение с ограниченными описанным выше образом привилегиями будет преднамеренно изменено злоумышленником и попадет на устройство пользователя, оно не сможет передать конфиденциальные данные никуда, кроме как на заранее заданный почтовый сервер.

Для рядовых пользователей не существует доверенных источников приложений. По данным компании ESET, до трети всех вирусов под Android распространяется через официальный магазин приложение Android Market[4].

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

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

Рассмотрим также приложение — менеджер контактов. Такое приложение, как минимум, обязано иметь привилегии на чтение и запись контактов, и для большинства ситуаций этого может быть достаточно. Теперь представим ситуацию, в которой пользователя попросили переслать данные определенного контакта в СМС-сообщении (или по электронной почте); для данной операции менеджеру контактов требуется привилегия отправки СМС-сообщений. Перед разработчиком приложений встает вопрос: нужно ли запрашивать пользователя о представлении привилегии отправки СМС-сообщений на постоянной основе, рискуя быть заподозренным в отправке нелегитимных сообщений, или же не предоставлять такую возможность пользователю вообще, пожертвовав удобством работы со своим приложением. Возможность предоставления «одноразовой» привилегии приложению с согласия пользователя была бы очень удобной. Необходимо заметить, что подобный подход используется в операционной системе Apple iOS для предоставления разрешений на отправку СМС-сообщения или осуществления телефонного звонка[2].

На основе рассмотренных выше примеров выделяются следующие возможности подсистемы привилегий Android, которые необходимо реализовать:

· возможность детализации привилегий (указание ip-адреса и порта, телефонного номера и т.д.);

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

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

Подсистема привилегий со стороны операционной системы

Каждое приложение Android имеет свой уникальный идентификатор и выполняется в отдельном экземпляре виртуальной машины Dalvik. Приложения взаимодействуют с системой с помощью вызовов API-функций.

Несколько другие типы взаимодействия с системой предоставляют объекты Content Provider и Intent, но рассматриваемая подсистема привилегий для них схожа с той, что используется для API

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

API-функции выполняются в три этапа. Сначала приложение вызывает открытый метод в библиотеке API. Затем метод API вызывает скрытый интерфейс в этой же библиотеке. Интерфейс реализован как RPC-стаб (объект, способный вызвать удаленную функцию). Наконец, RPC-стаб вызывает реализацию API-функции в системном процессе, которая и производит требуемую операцию, выполняя предварительно проверку достаточности прав.

Приложения Android могут так же содержать «родной» код ( код на языке C/C++). Такой код не может взаимодействовать с системой напрямую; вместо этого он должен создавать Java-методы для вызова API-функций, и поэтому он так же полностью контролируется подсистемой привилегий.

На рисунке 2 показан описанный выше процесс.

Рис. 2. Подсистема привилегий в Android

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

Для реализации возможности детализации привилегий необходимо реализовать классы для каждой привилегии с возможностью хранения необходимых данных. При проверке достаточности привилегий, система сможет учитывать эти данные. Что касается тех привилегий, которые реализуются с помощью Unix-групп, то здесь ситуация сложнее: недостаточно, скажем, иметь одну группу для приложений, которым разрешен доступ к сети Интернет. Для каждого сочетания адреса и порта необходимо создать отдельную группу и сокет. Тем не менее, число приложений на обычном устройстве под управлением Android редко превышает даже 100 штук, поэтому возникновение проблем, связанных с производительностью здесь маловероятно.

Для реализации опциональных привилегий достаточно разрешить разработчику определять, какие привилегии жизненно необходимы для его приложения, а какие — можно опустить. Разработчику приложений также необходимо помнить, что при вызове API-функции с недостаточными привилегиями выбрасывается исключение, класс которого унаследован от класса SecurityException; разработчик должен соответствующим образом обработать это исключение. Кроме того, система привилегий предоставляет возможность определения наличия необходимых привилегий с помощью методов стандартной библиотеки.

Для реализации возможности использования однократных привилегий существующий механизм привилегий необходимо доработать следующим образом:

1) приложение обращается к пользователю за предоставлением той или иной привилегии;

2) пользователь предоставляет такую привилегию;

3) приложение вызывает соответствующую API-функцию;

4) приложение лишается соответствующей привилегии.

Заключение

В данном докладе кратко рассмотрена подсистема привилегий Android и рассмотрены некоторые ее недостатки. Эти недостатки серьезно влияют на доверие пользователя к приложению, а также на безопасность системы в целом.

Предложены способы устранения указанных недостатков, которые могут быть реализованы на основе существующих прошивок Android с открытым исходным кодом.

Литература

1. International Data Corporation. http://www.idc.com/.

2. Nachenberg, C. A Window Into Mobile Device Security. Symantec, 2011.

3. Porter Felt, A., Chin, E., Hanna, S., Song, D., D. Wagner. Android Permissions Demystified. University of California, Berkeley.

4. ESET. http://www.eset.com/.