ユーザーと sudo

最初にシェルを得たら、脆弱性を探す前に実行ユーザーと所属グループを確認する。このページでは UID、補助グループ、ログイン可能なユーザー、sudo -l の読み方を扱う。許可されたコマンドの調査はsudo で実行できるプログラムに進む。

確認コマンド

追加確認例:

id
whoami
groups
getent passwd
getent group
umask
sudo -l

目的: 現在の UID/GID、補助グループ、ログイン可能ユーザー、sudo で越えられる境界を確認する。
前提条件: 対話 shell があること。sudo -l はパスワード入力を求める場合がある。
何を確認しているか: uid=, gid=, groups=、/bin/bash などのログイン shell、NOPASSWD, SETENV, wildcard、引数制限、禁止ルール。
期待される出力: (root) NOPASSWD: /usr/bin/python3 /path/script.py、Sorry, user ... may not run sudo、Command 'sudo' not found。
出力の解釈: sudo が使えなければ、localhost service、systemd、writable path、資格情報へ調査を移す。sudo が可能なら、許可されたコマンドが root で何を読むかを追う。
失敗した場合の切り分け: sudo 非導入、TTY 不足、パスワード要求、sudoers の完全一致、引数追加不可を分ける。
代替コマンド: cat /etc/passwd, find /etc/sudoers.d -maxdepth 1 -type f -readable -print, doas -C /etc/doas.conf。
状態変更: id と getent は読み取り専用。sudo -l は認証ログに残る可能性がある。パスワードを複数回誤入力しない。

uid=1000(user) は real UID。SUID binary 実行後に euid=0(root) が出た場合、effective UID が root になっている。
supplementary group は、writable directory や socket の接続権限に効く。
sudo -l の * は任意引数とは限らない。完全パス、引数、禁止ルール、環境変数のリセットを読む。
/etc/passwd の shell だけでは足りない。service user の home と group も見る。
Web や印刷のサービスアカウントと、ログイン shell を持つユーザーは別に記録する。
/proc/net/tcp の UID はソケット作成時の実効 UID を示す。待ち受けプロセスの実行ユーザーは、ss -p や /proc/<PID>/fd でプロセスを特定してから確認する。
sudo が拒否されたら、許可コマンドの変形は打ち切る。次の候補は localhost の高権限サービスである。

一般論: UID/GID はファイル権限、socket 接続、process visibility、SUID の効き方に直結する。

sudo ルールの中身（完全一致、禁止サブコマンド、許可コマンドが読むファイル）はsudo で実行できるプログラムにまとめた。