Разрешения системного приложения

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

Я думал, что следующий процесс достигнет моих целей:

  1. Укорените устройство
  2. Установить мое приложение как системное
  3. Запустите приложение и предоставьте ему права su
  4. Отключить устройство

Поскольку это будет системное приложение, а устройство не будет рутировано, пользователи не смогут удалить приложение. В чем я не уверен, так это в том, сохранит ли это приложение свои привилегии root после отключения устройства?

Любая обратная связь или понимание будет принята с благодарностью!

Вы не можете установить свое приложение как системное приложение, так как вам нужен тот же ключ подписи, который использовался для подписи рассматриваемого ПЗУ. Если устройство становится нерутированным, оно автоматически теряет root.
А как насчет таких приложений, как Titanium Backup Pro или /system/app mover, которые преобразуют пользовательские приложения в системные? Используя одно из этих приложений, пользовательское приложение можно сделать системным.
Даже если это сработает, что помешает кому-то снова рутировать устройство и удалить приложение?
Технически ничего. Но поскольку приложение, которое я хочу установить, предназначено для удаленного мониторинга и управления устройством, я могу сказать, есть ли у них такая возможность.
Как? Из приведенного выше заявления: «Я не хочу, чтобы они могли удалить приложение, и я не хочу, чтобы они имели root-доступ к устройству». дело в том, что они могут удалить его в любое время.. ничто не мешает им это сделать, даже с adb и usb-кабелем, сотрудники могут быть технически подкованы в этом, даже если вы об этом не знаете..
На самом деле, это было бы довольно просто сказать.... если приложение перестало сообщать, а проверка устройства показала, что они удалили его, я увольняю их за вмешательство в мое оборудование. Если в ходе мониторинга я обнаружу, что SuperUser.apk установлен, я знаю, что они повторно рутировали устройство, и я увольняю их за вмешательство в мое оборудование.
Хммм ... единственное, что я могу придумать, это создать собственное ПЗУ, которое зависит от того, о каком устройстве идет речь, если они все одинаковые, работа будет намного проще, если нет, у вас проблемы . И просто измените исходный код AOSP, чтобы предотвратить удаление диспетчера пакетов, то есть вам нужно взломать быстрое однострочное решение в его недрах и связать его с суперпользователем и вашим приложением, которое скрыто от просмотра.. кроме этого , если говорить об отсутствии самостоятельного подхода, то вам сильно не повезло!
@ t0mm13b На самом деле, этот подход TiBu должен работать: root → установить TiBu → преобразовать приложение в системное приложение (т.е. оно устанавливается в /system/apps) → удалить TiBu → удалить root. Сделанный. Тогда это приложение будет иметь доступ к уровням защиты «signatureOrSystem». Но предоставить ему root- доступ — это нечто другое (и, вероятно, здесь даже не нужно).

Ответы (1)

Как уже указывал ProNetGuru , для этого действительно можно использовать Titanium Backup :

  1. корень
  2. установить ТиБу
  3. конвертировать приложение в системное приложение (т.е. оно устанавливается в/system/apps
  4. удалить ТиБу
  5. выкорчевать.

Сделанный. Тогда это приложение будет иметь доступ к уровням защиты «signatureOrSystem» (если это указано в его манифесте).

Предоставление ему root-доступа — это нечто другое, но, вероятно, здесь это даже не нужно.

Чтобы приложение имело signatureOrSystemуровень, оно должно быть android:sharedUserId="android.uid.system"в манифесте и подписано тем же ключом подписи, что и ПЗУ... tbh, никогда не пробовал.. для обычного приложения, которое имеет нормальный манифест, как отсутствие вышеуказанного тега не обязательно означает, что он имеет этот уровень защиты signalOrSystem, даже если он был установлен как «системное приложение».
Ой. Возможно, я ошибся в этой части (тогда это только «система» уровня защиты; но в чем, пожалуйста, разница между «подписью» и «signatureOrSystem»? Нет отдельной «системы уровня защиты»). Но, пожалуйста, поправьте меня: я думал, что невозможно «предоставить корневой доступ к приложению», а затем отключить устройство, все еще сохраняя это прилипание. Так что это самое близкое, к чему можно добраться, учитывая обстоятельства.
signatureOrSystemуровень защиты означает, что он может обойтись rm -rf /без рута! И делать то, что может делать обычный корень (uid 0) - это предел. Существует много разных sharedUserIdуровней, например: android.uid.phone, если этот android:sharedUserIdтег имеет приведенный выше пример, это означает, что приложение может делать все, что связано со слоем телефонии, и ничего больше. Это гораздо более тонкий контроль доступа за кулисами для приложений системного уровня, а также для минимизации нарушений и злонамеренных действий. Все, что делает TiBu, это перемонтирует систему r/w и перемещает туда приложение, больше ничего.
И если у этих системных приложений, т.е. встроенных в ПЗУ, удалена цифровая подпись, они откажутся запускаться, поэтому вы можете понять, почему уровень защиты ниже обычных разрешений манифеста Android.
Кроме того, чтобы добавить к этому больше размышлений, предположим, что OP ушел и создал свое собственное ПЗУ с указанным приложением, имеющим этот тег в манифесте, установленным в систему и подписанным с помощью вновь созданной подписи ПЗУ - счастливые дни. Затем, если ОП решит обновить указанное приложение через игровой магазин и распространить оттуда, оно не сможет обновиться, потому что ключи подписи не совпадают, и единственный способ заставить обновление работать будет означать... да, удалить систему приложение и установить из игрового магазина! Фу сложно все это объяснять. :)
Фу. Так что кажется, что весь вопрос скорее XY. О чем мы говорим? Что действительно нужно? Почему это должно быть «системное приложение с root-доступом»? Может быть, я лучше сразу удалю свой ответ?
Это больше похоже на вопрос, заданный OP как XY, и да, OP действительно сказал: «Запустите приложение и предоставьте ему права su» и отключите его, что ставит OP в безвыходную ситуацию. Ответ ниже краток и прост и является правильным ответом, несмотря на то, что ОП не принимает ничего другого...
Хорошо, так что я уйду на этом этапе. ОП должен проверить, работает ли это для него, а затем принять тот из двух ответов, который оказался правильным.
оно мутное!!! :Делать/
Я очень ценю всю информацию и понимание, предоставленное каждым. Я буду тестировать это на следующей неделе или около того, приму ответ и сообщу всем, как это работает.
@ t0mm13b ты немного зеленый. Проверьте свои факты (и, пожалуйста, не обижайтесь). Вы просто ошибаетесь во многом из того, что вы сказали в этих комментариях. Дайте знать, если у вас появятся вопросы. Системные приложения не могут rm -rf /. Системный раздел доступен только для чтения. Вам нужно перемонтировать его r/w. Кроме того, вам не нужно иметь ту же подпись, что и системные приложения, чтобы быть системным приложением. signatureOrSystemна разрешении не имеет ничего общего с системным приложением. Он предоставляется приложениям в системной папке ИЛИ приложениям, подписанным тем же ключом, что и сама система.
@dcow, хотя я могу подтвердить большинство ваших фактов: разве «системное приложение» точно не определено как установленное в системной папке? И не могли бы они просто перемонтировать себя перед казнью rm -rf? Но, конечно, вы правы, говоря, что «просто иметь разрешение в манифесте недостаточно»: правда, оно должно быть либо подписано «системным ключом», либо, по крайней мере, установлено как системное приложение в первую очередь, чтобы это разрешение было предоставлено - но это то, что делает шаг № 3 ответа.
Разрешения системного приложения
СпросиСетьПолитика конфиденциальности1y, 0v