SELinuxおよびchrootシステムコール

TL; DR：これは、すべてのAndroidマシンで機能する、移植可能な開発者指向のルート化プロセスの最終ステップに関する質問です。これはエクスプロイトに基づいたものではありません。開発者として自分のマシンに対して法的にも道徳的にも許可されているものです。答えが得られ、Debian内でchrootを管理する場合、タブレットへのルートアクセスを必要とし、疑わしい起源を信頼したくないすべての仲間の開発者のために、このプロセスのすべてのステップを詳述する簡潔なブログ投稿を行いますマシン（ボットネットメンバー？）に何を知っているかを示す「ワンクリックルート」...唯一の依存関係は、マシンのカーネルソース（メーカーが法的に提供する義務がある）とブートパーティションイメージ（boot.img）、これはメーカー提供の無線アップデート内の99％の時間、またはスタンドアロンのフラッシュ可能なイメージとして個別にダウンロード可能です。

そのため、新しいAndroidタブレットで自由時間を過ごした1週間が過ぎました。

そして、Android 5.0.2タブレットでルートを達成するために、移植性のある開発者指向のプロセスを作成することにほぼ完全に成功しました。

しかし、まだ1つ欠けていることがありますdebootstrap-chroot を実行できません（これは-ed Debian を実行する必要があります！）

これまでにやったこと

1. まず、タブレットの（メーカー提供の）カーネルソースにマイナーパッチを適用してから、独自のカーネルをコンパイルしました。ここで、SELINUX強制モードを変更するためのチェックを無効にしました。具体的には...

で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,

2. 私はその後、私のinitrdイメージのを変え/default.prop含むように：ro.secure=0とro.debuggable=1

3. 私の製造業者のものinitrd.imgが欠落しているため、https：//android.googlesource.com/platform/system/extras/+/master/su/su.cからコンパイルし、結果のバイナリを/sbin/su SUIDルート（chmod 04755 /sbin/su）に設定されていることを確認しました。

その後、前の投稿のエピソード2で説明したように、新しいカーネルと新しいinitrdをパッケージ化し、自分のイメージから起動しました。

adb reboot boot-loader ; fastboot boot myboot.img

だから、あなたはルートですか？

はい、最初は成功したように見えました：

$ 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

そして今、私はルートを達成しました：

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でフォーマットされた2番目のパーティションをマウントできません。

また、私の素敵なdebootstrap-ed Debianにchrootできません：

root@K01E_2:/ # chroot /data/debian/ /bin/bash                             
chroot() fail
Operation not permitted

SELinuxが原因ですか？

わからない-私はSELinuxが初めて（1週間前）です。私はあなたがそれを眠らせたとき（getenforce「Permissive」と報告さ）、もう干渉しない ...

どうやら、私は間違っていた。ウサギの穴を下ってまた行きます...

私のプロセスのコンテキストが原因でしょうか？

id返されたことを思い出してください... "uid = 0（root）gid = 0（root）... context = u：r：shell：s0 "

そのコンテキストを変更できますか？ルートとすべてである、私はから離れることができます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 ...
...

OK、いくつかの可能性！特に、それ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 INGですか？

どんなアドバイスでも大歓迎です...

誰が私をchrootするのを妨げているのですか？

それはSELinuxではありませんでした-それは野生のガチョウの追跡でした（getenforce「Permissive」を返すことは、SELinuxが実際にはもはや写真に写っていないことを意味します）。

犯人- printkカーネルのソースにかなりの数を追加して両方の障害を追跡した後chroot、mount- 能力であることが判明しました。具体的には、Androidの「機能制限セット」-あなたはman（man 7 capabilities）でそれらのすべてを読むことができ、それらを調べることはこれまでになかったと告白します-私の日常のUNIXタスクはそれらに依存していたので、私はこれを試してみませんでした... Linuxボックスを確認してください：

$ getfattr -d -m - /sbin/ping
getfattr: Removing leading '/' from absolute path names
# file: sbin/ping
security.capability=0s......

見る？PingはSUIDルートではなくなりました- ファイルシステムの拡張属性に保存された情報を使用しますにして、rawソケットレイヤーにアクセスできることを確認します（つまり、IPレベルでICMPを実行できます）。

とにかく、私は脱線します-私のカーネルの「私の能力セットを落とす」を止めた手術点-おそらく嫌な「すべてを行進させる」方法で-これは（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

こんにちは、私の素敵なDebian :-)

ああ、「ルートチェッカー」も機能します-「su.c」を切り取ったので、タブレットの全員がルートになることができます：

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、誰もとで自分の祖母をさせない、と:-)