Введение
Согласно исследованию известной компании International Data Corporation [1] в первом квартале 2015 года операционная система Android занимает лидирующую позицию на рынке мобильных операционных систем с долей в 78%. Такую популярность можно объяснить, с одной стороны, простотой и удобством ее использования, а с другой – надежностью ее системы безопасности, важной частью которой является подсистема привилегий. Тем не менее, несмотря на кажущееся удобство указанной подсистемы, ей недостает гибкости: одним из серьёзных недостатков является отсутствие возможности задания опциональных привилегий. Имея такую возможность, пользователь получает больший контроль за работой приложения. В данной работе будут рассмотрены практические аспекты реализации указанных возможностей в ОС Android.
Описание подсистемы привилегий
При установке приложения пользователю предоставляется список привилегий, которые требуются приложению для его корректной работы. Привилегии представляют собой разрешения на доступ к потенциально опасным ресурсам, таким как доступ к сети Интернет, чтение идентификационных данных устройства, данных календаря, списка контактов и т. д. Пользователь может просмотреть привилегии и определить, следует ли предоставлять приложению запрашиваемые привилегии; при этом пользователь должен либо предоставить приложению все запрашиваемые привилегии, либо вовсе отказаться от установки приложения.
Идея опциональных разрешений заключается в том, что некоторые (указанные разработчиком) привилегии помечаются особым образом, и могут быть или не быть предоставлены приложению при установке. Если привилегия не предоставляется, приложение просто не будет использовать соответствующие функции в своей работе. Разумеется, критичные для работы приложения разрешения не должны помечаться как опциональные. При установке приложения с опциональными привилегиями пользователь может, понимая логику работы программы, определить, требуются ли те или иные привилегии в его случае или нет. Если привилегии не требуются, пользователь не предоставляет их, ограничивая возможности, а, следовательно, и потенциальную опасность приложения. Например, разработчик игры может предоставлять возможность публикации результатов игры на своём портале в сети Интернет. Если он запрашивает для своей игры опциональное разрешение на доступ к сети, то пользователь может решить для себя, нужна ли ему эта функциональность и предоставить соответствующий набор привилегий. В таком случае ни один пользователь не откажется от установки приложения, опасаясь, что приложение будет злоупотреблять возможностью доступа в сеть.
Модификация подсистемы привилегий
Для реализации модифицированной подсистемы привилегий, то есть подсистемы привилегий с возможностью задания опциональных привилегий необходимо рассмотреть два основных вопроса: собственно реализация данной возможности и интеграция существующих приложений, написанных без учёта этой возможности.
Для реализации опциональных привилегий необходимо предоставить разработчику возможность описывать привилегии как опциональные. В обычной версии описание требуемой привилегии имеет следующий синтаксис:
<uses-permission android:name=»string» android:maxSdkVersion=»integer» />
В атрибуте name указывается название требуемой привилегии, а в атрибуте maxSdkVersion — максимальная версия Android, для которой требуется данное разрешение. Для описания опционального разрешения помимо указанного тега используется ещё один тег метаданных следующего вида:
<meta-data android:name=»string» android:value=»string» />,
где в качестве значения android:name используется имя привилегии, а в качестве значения строка “optional”. Такой подход позволяет не изменять существующую структуру файла манифеста (а, значит, и не меняя существующие утилиты для сборки пакета приложения), добавляя при этом нужную функциональность.
При установке приложения пользователю представляется возможность определить, требуется ли ему конкретная привилегия или нет. На рисунке 1 показан экран с возможностью выбора конечного набора привилегий.
Пользователь может включать и выключать соответствующие привилегии, определяя, будут ли они предоставлены устанавливаемому приложению или нет. С целью интеграции существующих приложений в модифицированную систему существует возможность не предоставлять любую запрашиваемую привилегию, а не только те, что разработчик отметил как опциональные.
После того как пользователь определил конечный набор привилегий, предоставляемых приложению, оно устанавливается. Данные о предоставленных привилегиях сохраняются в отдельном конфигурационном файле (поскольку эти данные отсутствуют в пакете приложения). При попытке получить доступ к потенциально опасным системным ресурсам или конфиденциальным данным владельца приложение будет запрашивать вызов соответствующей API-функции. Её вызов в свою очередь будет снабжаться проверкой наличия соответствующей привилегии. На этом этапе привилегия может быть предоставлена, не предоставлена или охраняемый ей ресурс может быть замаскирован.
В первом случае просто выполняется вызов функции и возвращается реальное значение. Если привилегия опциональная и она не предоставлена, то вызов функции приводит к генерации исключения системы безопасности SecurityException [2]. Приложение должно обработать соответствующее исключение, так как разработчик знал, что данная привилегия может и не быть предоставлена. В случае, если это приложение было написано для ОС Android без учёта возможностей опциональных привилегий, то приложение, скорее всего, не обработает данное исключение и будет остановлено; фактически это означает, что приложением нельзя будет пользоваться. Для решения этой проблемы и применяется метод маскировки ресурса: функция, запрашиваемая приложением, выполняется, но возвращается фиктивный ресурс. Например, если приложение запрашивало доступ к службе вибрации, то вызов выполняется, но реально устройство не вибрирует; если запрашивался доступ к списку контактов, то он возвращается пустым; запрос на доступ к сети Интернет обрывается по тайм-ауту. Таким образом приложение продолжает работать корректно даже несмотря на отсутствие привилегии. Для каждой привилегии можно также разработать отдельный фиктивный ресурс, который помешает приложению отличить его фиктивность; например, можно хранить два списка контактов, один для приложений, имеющих привилегию, другой – для приложений, для которых эта привилегия маскируется.
Заключение
Рассмотренная в статье модификация подсистемы привилегий ОС Android позволяет усилить контроль за работой приложений, уменьшив риски, связанные с доступом к конфиденциальным данным и системным ресурсам. Этот подход позволят разработчикам определять необязательные привилегии, что увеличивает доверие пользователей и, следовательно, потенциальную клиентскую аудиторию разработчика. Кроме того, рассмотренный подход с маскировкой ресурсов системы также позволяет использовать в системе огромное количество уже существующих приложений из Google Play (около полутора миллионов приложений на май 2015 года [3]).
Список литературы
- International Data Corporation. https://www.idc.com/.
- Портал разработчиков ОС Android. https://developer.android.com/.
- Статистика AppBrain. type=»book» name=»Инструментальная среда для маскирования привилегий ОС Android» description=»Операционная система Android имеет достаточно развитые средства защиты от вредоносного программного обеспечения, основой которых является подсистема привилегий, позволяющая разграничить для приложений доступ к важным системным ресурсам и конфиденциальным данным владельца мобильного устройства. В данной статье рассматривается один из недостатков этой подсистемы: невозможность задания опциональных привилегий. Описан подход, позволяющий устранить этот недостаток. Подход основан на маскировании определенного ресурса для приложения: приложение работает с фиктивным ресурсом и не имеет возможности распознать ресурс как фиктивный. Рассмотрены вопросы реализации данного подхода в ОС Android для устранения существующих недостатков системы.» author=»Новик А. К.» publisher=»БАСАРАНОВИЧ ЕКАТЕРИНА» pubdate=»2017-03-13″ edition=»ЕВРАЗИЙСКИЙ СОЮЗ УЧЕНЫХ_30.05.2015_05(14)» ebook=»yes» ]