тл; Д.Р.: Это вопрос о последнем этапе переносимого, ориентированного на разработчиков процесса рутирования, который работает на всех машинах Android. Это не основано на каком-либо эксплойте — это то, что нам, как разработчикам, позволено делать с нашими собственными машинами по закону и морально. Если я получу ответ и смогу выполнить chroot в моем Debian, я сделаю краткий пост в блоге с подробным описанием всех шагов этого процесса для всех коллег-разработчиков, которые хотят получить root-доступ к своим планшетам — и не хотят доверять сомнительному происхождению. «корни в один клик», которые делают черт знает что со своими машинами (членами ботнета?) ... Единственными зависимостями будут исходные коды ядра машины (которые производитель по закону обязан предоставить) и образ загрузочного раздела (boot.img), который в 99% случаев находится в составе беспроводных обновлений, предоставляемых производителем, или загружается индивидуально в виде отдельного образа с возможностью прошивки.
Итак, прошла неделя, в течение которой я проводил все свое свободное время за своим новым Android-планшетом.
И мне это почти полностью удалось — создать переносимый, ориентированный на разработчиков процесс, для получения рута на моем планшете Android 5.0.2.
Но кое-чего пока не хватает — я не могу сделать chroot (который мне нужен, чтобы запустить мой debootstrap-ed Debian!)
Что я сделал до сих пор
В security/selinux/selinuxfs.c:
...
if (new_value != selinux_enforcing) {
/* Commented out by ttsiodras.
length = task_has_security(current, SECURITY__SETENFORCE);
if (length)
goto out;
*/
audit_log(current->audit_context, GFP_KERNEL, AUDIT_MAC_STATUS,
"enforcing=%d old_enforcing=%d auid=%u ses=%u",
new_value, selinux_enforcing,
Затем я изменил образ initrd, /default.propчтобы он содержал: ro.secure=0иro.debuggable=1
Поскольку у моего производителя его не initrd.imgбыло, я также скомпилировал его su.cс https://android.googlesource.com/platform/system/extras/+/master/su/ и поместил полученный двоичный файл в папку /sbin/su, убедившись, что для него задан корень SUID ( chmod 04755 /sbin/su) .
После этого я упаковал новое ядро и новый initrd, как я объяснял в Эпизоде 2 моего предыдущего поста , и загрузился с собственного образа:
adb reboot boot-loader ; fastboot boot myboot.img
Итак, вы root?
Да, изначально это казалось успешным:
$ adb shell
shell@K01E_2:/ $ id
uid=2000(shell) gid=2000(shell) groups=1004(input),1007(log),1011(adb),
1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),
3003(inet),3006(net_bw_stats)
context=u:r:shell:s0
shell@K01E_2:/ $ ls -l /sbin/su /sbin/_su
-rwxr-xr-x root root 131 2015-10-03 10:44 su
-rwsr-xr-x root root 9420 2015-10-03 01:31 _su
(the _su is the binary I compiled, set to SUID root, and "su" is
a script I wrote to tell "su" to add me to all these groups...)
shell@K01E_2:/ $ cat /sbin/su
#!/system/bin/sh
export PATH=/system/bin:$PATH
exec /sbin/_su 0,0,1000,1028,2000,2001,1004,1007,1011,1015,\
1028,3001,3002,3003,3006
И теперь я получил root:
shell@K01E_2:/ $ su
root@K01E_2:/ # id
uid=0(root) gid=0(root)
groups=1000(system),1004(input),1007(log),1011(adb),
1015(sdcard_rw),1028(sdcard_r),1028(sdcard_r),2000(shell),2001(cache),
3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats)
context=u:r:shell:s0
Я на 100% уверен, что я root - не только потому id, что так сказано, но и потому, что я также могу делать то, что обычные процессы определенно не могут:
root@K01E_2:/ # ls -l /dev/block/platform/msm_sdcc.1/by-name/boot
lrwxrwxrwx root root 2015-10-03 10:47 boot -> /dev/block/mmcblk0p16
root@K01E_2:/ # dd if=/dev/block/mmcblk0p16 of=/dev/null bs=1M
16+0 records in
16+0 records out
16777216 bytes transferred in 0.569 secs (29485441 bytes/sec)
О чудо — я наконец-то могу читать необработанные разделы с моего планшета!
И SELinux действительно находится в режиме «вниз, собака»:
root@K01E_2:/ # getenforce
Permissive
Но... есть еще вещи, которые я не могу сделать:
root@K01E_2:/ # mkdir /my_mnt
root@K01E_2:/ # mount -t ext4 /dev/block/mmcblk1p2 /my_mnt
mount: Operation not permitted
То есть я не могу смонтировать второй раздел своей внешней SD-карты, отформатированный в EXT4-fs.
Я также не могу подключиться к моему прекрасному debootstrap-ed Debian:
root@K01E_2:/ # chroot /data/debian/ /bin/bash
chroot() fail
Operation not permitted
Это из-за SELinux?
Я не знаю - я новичок (очень новичок - всего неделю) в SELinux. Я думал, что когда его усыпляешь ( getenforceрепортаж "Разрешающий"), он уже не мешает...
Видимо, я ошибся. Мы снова спускаемся в кроличью нору...
Может ли это быть из-за моего контекста процесса?
Помните, что idвозвращено... "uid=0(root) gid=0(root)... context=u:r:shell:s0 "
Могу ли я изменить этот контекст? Будучи root и все такое, могу ли я отказаться от shell? И если да, то на что перейти?
Ответ на первый вопрос таков runcon:
shell@K01E_2:/ $ runcon u:r:debuggerd:s0 /sbin/su
root@K01E_2:/ # id
uid=0(root) gid=0(root)... context=u:r:debuggerd:s0
Хороший. Но какой контекст позволит мне mountи chroot?
Прочитав еще немного о SELinux, вернувшись на свою основную машину, я анализирую /sepolicyфайл в корневом каталоге initrd.img:
linuxbox$ $ sesearch -A sepolicy | grep chroot
allow init_shell init_shell : capability { chown sys_chroot ...
allow init init : capability { chown dac_read_search sys_chroot ...
allow kernel kernel : capability { chown dac_override sys_chroot ...
allow asus-dbug-d asus-dbug-d : capability { chown sys_chroot ...
...
Хорошо, несколько возможностей! Особенно то, что kernelкажется многообещающим:
shell@K01E_2:/ $ runcon u:r:kernel:s0 /sbin/su
root@K01E_2:/ # id
uid=0(root) gid=0(root)... context=u:r:kernel:s0
root@K01E_2:/ # chroot /data/debian/ /bin/bash
chroot() fail
Operation not permitted
Штопать.
Кто, черт возьми, мешает мне chrootинг?
Приветствуются любые советы...
Кто, черт возьми, блокирует меня от chroot?
Это был не SELinux — это была погоня за дикими гусями ( getenforceвозврат «Permissive» означает, что SELinux действительно больше не фигурирует).
Виновником — после добавления достаточного количества printkв исходники ядра для отслеживания сбоев и того, chrootи другого mount— оказались возможности . В частности, «ограничивающий набор возможностей» Android — вы можете прочитать о них все через свой man( man 7 capabilities), и я признаюсь, что никогда прежде не удосужился изучить их — мои повседневные задачи UNIX зависели от них, и я понятия не имел… попробуйте это в ваш Linux Box, чтобы убедиться в этом:
$ getfattr -d -m - /sbin/ping
getfattr: Removing leading '/' from absolute path names
# file: sbin/ping
security.capability=0s......
Видеть? Ping больше не является корневым SUID - он использует информацию, хранящуюся в расширенных атрибутах файловой системы, чтобы знать, что у него есть доступ к слою необработанных сокетов (поэтому он может выполнять свои действия ICMP - то есть на уровне IP).
Во всяком случае, я отвлекся - точка хирургии в моем ядре, где я остановил "отбрасывание моего набора возможностей" - возможно, отвратительным способом "пусть все маршируют" - был следующим ( security/commoncap.c):
static long cap_prctl_drop(struct cred *new, unsigned long cap)
{
if (!capable(CAP_SETPCAP))
return -EPERM;
if (!cap_valid(cap))
return -EINVAL;
// ttsiodras: come in, everyone, the water's fine!
//cap_lower(new->cap_bset, cap);
return 0;
}
Это означает, что возможности НИКОГДА не сбрасываются — действительно, очень безопасная конфигурация :-)
$ adb shell
shell@K01E_2:/ $ su
root@K01E_2:/ # chroot /data/debian/ /bin/bash
root@localhost:/# export PATH=/bin:/sbin:/usr/bin:/usr/sbin:\
/usr/local/bin:$PATH
root@localhost:/# cat /etc/issue
Debian GNU/Linux 8 \n \l
Привет, мой милый Дебиан :-)
Да, и "Root checker" тоже работает - я отрезал "su.c", так что все в моем планшете могут стать root:
int main(int argc, char **argv)
{
struct passwd *pw;
uid_t uid, myuid;
gid_t gid, gids[50];
/* Until we have something better, only root and shell can use su. */
myuid = getuid();
//
// ttsiodras - Oh no, you don't :-)
//
//if (myuid != AID_ROOT && myuid != AID_SHELL) {
// fprintf(stderr,"su: uid %d not allowed to su\n", myuid);
// return 1;
//}
Теперь, когда это работает, я должен заставить его работать правильно - т.е. разрешить только моим termuxи Terminal Emulatorпользователям вызывать suи chroot, а не всем и их бабушкам :-)
1110101001
тциодрас
тциодрас
fastboot boot my.img. Я считаю, что сообщество рутеров называет это привязанным рутированием :-) И, конечно, я мог бы его прошить - если бы захотел.