☰

機能を追加して権限を失うのですか？

tag-icon • tag-icon namespace unshare
機能を追加して権限を失うのですか？

説明できない次の現象を観察しました。CAP_SYS_ADMIN機能を追加した後は、unshare書き込みができなくなります/proc/self/setgroups。

実際にこのファイルに書き込む必要機能がありますが、これはユーザーの名前空間を変更することによって達成されます。なぜ次へ追加親プロセスの機能によってファイルの書き込みがブロックされますか？

me@myhost:~$ unshare -r
root@myhost:~# exit
logout

me@myhost:~$ sudo setcap cap_sys_admin=ep /usr/bin/unshare
me@myhost:~$ unshare -r
unshare: cannot open /proc/self/setgroups: Permission denied

me@myhost:~$ sudo setcap cap_sys_admin= /usr/bin/unshare
me@myhost:~$ unshare -r
root@myhost:~#

ちなみに：私はカーネルバージョン4.4とutil-linux（付属）バージョンunshare2.27.1でUbuntu 16.04.4 LTSを実行しています。

答え1

ここで何が起こるのかは、「共有解除」プロセスにファイル書き込みsetgroups（およびuid_maps、）権限がないことです。gid_maps外部ユーザーの名前空間。

その名前空間の擬似ファイルは/proc/<PID>ルートによって所有されており、有効なuidがまだ自分のユーザーであるかのようにそのファイルに書き込む権限がありません。

たとえば、バックグラウンドでプロセスを実行し、実行中にファイルの権限を確認すると、sleepそれを簡単に視覚化できます（そしてまったく同じように動作します）。setgroupsuid_mapsgid_maps

まず、アドインなしでバイナリを使用します。

$ cp /usr/bin/sleep .
$ ./sleep 10 &
[1] 11209
$ ls -l /proc/11209/setgroups
-rw-r--r--. 1 myuser myuser 0 Jul 31 12:33 /proc/11209/setgroups
[1]+  Done                    ./sleep 10
$

次に、ここにいくつかのファイル機能を追加し、所有権の変更を見てみましょう。

$ sudo setcap cap_net_bind_service=ep sleep
$ ./sleep 10 &
[1] 11220
$ ls -l /proc/11220/setgroups 
-rw-r--r--. 1 root root 0 Jul 31 12:34 /proc/11220/setgroups
[1]+  Done                    ./sleep 10
$

ファイルの所有権は、/proc/<PID>Linuxカーネルの「dumpable」フラグによって制御されます。このフラグは、権限のあるプロセスで権限のないユーザーに情報が漏洩するのを防ぐために使用されます。

unshareアドインを実行していますが、まだrootではないユーザーを使用していると思う場合効果的なuid、rootが所有するこれらの擬似ファイルへの書き込みアクセスは、オペレーティングシステムの一般的なアクセス制御によってブロックされます。

PR_GET_DUMPABLE以下を使用して、「dumpable」フラグの値を確認できます。prctl(2)システムコール。

説明では、PR_SET_DUMPABLE次のことも確認できます。

通常、このフラグは1に設定されます。ただし、/proc/sys/fs/suid_dumpable次の条件では、ファイルに含まれる現在の値（デフォルトは0）にリセットされます。

[...]

  • プロセスはexecve(2)ファイル機能を持​​つプログラムを実行（）します。capabilities(7)）、しかし、取得した許容容量がプロセスですでに許容した容量を超える場合にのみ適用されます。

これがunshareファイル機能を備えたバイナリの場合です。

興味深いことに、rootが所有するsetuidバイナリを使用すると、unshareこの問題は発生しません。はい、「dumpable」フラグがクリアされ、その中のファイルは/proc/<PID>ルートが所有するようになります。しかし、効果的なuidを考えると返品setuid バイナリを実行すると、root アクセスが許可されます。

unshareこの場合、特定の設定を処理できないロジックに関連する他の問題が発生します（おそらく、有効なuidと実際のuidの間の矛盾に関連しています）。

$ cp /usr/bin/unshare .
$ sudo setcap -r unshare
$ sudo chown root:root unshare
$ sudo chmod 4711 unshare
$ ./unshare -r
-bash: cannot set uid to 65534: effective uid 0: Invalid argument
-bash-4.4$

また、「ダンプ可能」フラグのクリアは、ファイル機能が設定されたバイナリを実行するとトリガーされます。他の方法でアドインを入手すると、この問題は発生しない可能性があります。たとえば、「環境」機能を使用することは、新しいユーザーネームスペースの共有をキャンセルするときに問題が発生することなく、ネームスペースの外側でアドインを取得するのに最適な方法です。

（残念ながら、まだ環境機能のためのツールはあまりありません。libcapサポートは現在、ほとんどのディストリビューションで利用可能な最新のgitバージョン2.25でのみ利用可能です。capshかなり低いレベルなので、入手は簡単ではありません。ここ最新の環境機能の使用に関するcapsh詳細が追加されました。私も試してみましたが、systemd-runそこでも環境機能を実際に設定することはできませんでした。それにもかかわらず、機能、ルート以外のユーザー、およびユーザーの名前空間が必要な場合は、それらを調べる必要があります。 )

関連情報