「うちのサーバー、知らないうちに変な権限を持ったコマンドが仕込まれていないか」——そんな不安を解消するのが、SUIDとCapabilityの点検です。find / -perm -4000とgetcap -r /という2つのコマンドだけで、root権限に直結する入口を自分の手で洗い出せます。専門知識がなくてもコピペで実行できる手順を、出力例の読み方まで含めて解説します。
SUID・Capabilityが権限昇格の「入口」になる理由
SUID（Set User ID）は、実行するとファイルの所有者（多くはroot）の権限で動くファイルの目印です。たとえば一般ユーザーがpasswdコマンドで自分のパスワードを変更できるのは、このファイルにSUIDが付いていて一時的にroot権限で動くためです。便利な仕組みですが、悪意あるプログラムにこの目印を付けられると、一般ユーザーの権限のまま実行するだけでroot権限を握られてしまいます。
CapabilityはSUIDをさらに細かくした仕組みで、「root権限まるごと」ではなく「ネットワークの生パケットを扱う権限だけ」のように部分的な権限をファイルに与えられます。たとえばpingコマンドは、Ubuntu/Debianでは近年SUIDではなくCapabilityで最小限の権限だけを持つように変わっています。範囲が狭い分安全ではありますが、強力なCapability（後述）が意図せず付いていれば同じくroot権限昇格の入口になります。
2026年8月27日には、Linuxカーネルの権限昇格の脆弱性「CVE-2026-53362」(通称Frag Gap、CVSSv3.1で7.8）がCISAの悪用確認済み脆弱性カタログ（KEV）に追加されました。IPv6パケット生成処理の不具合を突いて一般ユーザーがroot権限を取得できるというもので、エクスプロイトコードも公開済みです。また8月4日には19年以上見過ごされていたカーネルのゼロデイ「CVE-2026-43456」がGoogleのkernelCTFで報告され8万ドル超の報奨金が支払われるなど、カーネル自体の権限昇格バグは他人事ではありません。ただし、これらのカーネルバグ自体はaptのアップデートで塞ぐものです（関連: Ubuntu apt自動更新の点検2026年8月版）。SUID/Capabilityの点検は、そうしたカーネルバグとは別に「すでに誰か（攻撃者やマルウェア）が裏口として仕込んだ不審なファイルがないか」を自分の目で確認するためのものです。
find / -perm -4000 でSUIDバイナリを洗い出す
実行するコマンドと見るポイント
次のコマンドをそのままコピーして実行してください。読み取り専用の確認コマンドで、システムの設定を一切変更しません。sudoを付けているのは、権限の都合で読めないディレクトリまで含めて漏れなく調べるためです。
sudo find / -xdev -perm -4000 -type f 2>/dev/nullこれは「ファイルシステム全体（-xdevで他のディスクや/procのような仮想ファイルシステムはまたがず本体だけ）から、SUIDビットが立っている（-perm -4000）通常ファイル（-type f）を探す」というコマンドです。2>/dev/nullは権限不足で読めないディレクトリのエラーメッセージを画面に出さず捨てる指定です。
出力例は次のようになります。
/usr/bin/sudo
/usr/bin/passwd
/usr/bin/su
/usr/bin/mount
/usr/bin/umount
/usr/bin/newgrp
/usr/bin/gpasswd
/usr/bin/chsh
/usr/bin/chfn
/usr/lib/openssh/ssh-keysign
/usr/lib/policykit-1/polkit-agent-helper-1正常/異常の見分け方（ベースライン表）
見るべきポイントは2つだけです。(1) パスが/usr/binや/usr/sbinなど標準的な場所か、(2) その1点でよいので、見覚えのないパスがないかです。
パス | 役割 | 判定 |
|---|---|---|
/usr/bin/passwd, /usr/bin/su, /usr/bin/sudo | パスワード変更・ユーザー切替に必須 | 正常（標準搭載） |
/usr/bin/mount, /usr/bin/umount | 一般ユーザーによるディスクマウント | 正常（標準搭載） |
/usr/lib/openssh/ssh-keysign | SSHのホストベース認証用 | 正常（openssh-client導入時） |
/tmp/xxx, /var/tmp/xxx, /dev/shm/xxx, /home/ユーザー名配下の実行ファイル | 本来SUIDが付く理由がない場所 | 要調査。バックドアの典型的な設置場所 |
一覧にあるが見覚えのない名前のファイル | - | 要調査 |
次にやること：見覚えのないパスが出たら、まずそのファイルがどのパッケージに属するか確認します。
dpkg -S /path/to/怪しいファイルどのパッケージにも属さない（「no path found」等が返る）場合はかなり危険な兆候です。そのマシンをネットワークから切り離す、他のPCから調査するなど被害拡大を止める行動を優先し、必要なら第三者にセカンドオピニオンを求めてください。パッケージには属しているがSUIDが不要と判断した場合は、次のコマンドでSUIDビットだけを外せます（ファイル自体の削除ではないので安全に戻せます）。
sudo chmod u-s /path/to/ファイル元に戻す場合はsudo chmod u+s /path/to/ファイル、あるいはそのパッケージを入れ直せば標準状態に戻ります（sudo apt install --reinstall パッケージ名）。
getcap -r / でCapabilityバイナリを洗い出す
実行するコマンドと見るポイント
getcapコマンドはUbuntu/Debianの多くの環境で標準搭載済みですが、「command not found」と出た場合だけ次を実行してください（設定変更ではなく単なるツール追加です）。
sudo apt install libcap2-bin本体の点検コマンドは次の1行です。こちらも読み取り専用です。
sudo getcap -r / 2>/dev/null-rは再帰的に（サブディレクトリまで含めて）探すという意味です。Capabilityはファイルの権限ビットではなく拡張属性として保存されているため、find -permでは見つからず、専用のgetcapコマンドが必要になります。
出力例は次のようになります。
/usr/bin/ping cap_net_raw=ep
/usr/bin/mtr-packet cap_net_raw=ep
/usr/lib/x86_64-linux-gnu/gstreamer-1.0/gst-plugin-scanner cap_sys_resource=ep正常/異常の見分け方
キーになるのは=epの前に書かれているCapability名です。ネットワーク系ツールのcap_net_raw（生パケットの送受信）やcap_net_bind_service（1024番未満の特権ポートを一般ユーザーでも使える権限。自分でNode.jsやPythonのWebサーバーを80番ポートで動かすために設定した経験があれば見覚えがあるはずです）は日常的に使われるもので、標準ツールに付いているぶんには正常です。
一方で次のCapabilityが、心当たりのないファイルに付いている場合はほぼroot権限を丸ごと渡しているのと同じため最重要の要調査対象です。
cap_setuid— 任意のユーザーIDに成りすませるcap_dac_override— ファイルの権限チェックを無視できるcap_sys_admin— 「なんでもできる」に近い広範な管理権限
次にやること：SUIDと同様にdpkg -S /path/to/ファイルで所属パッケージを確認し、不審であれば調査・隔離を優先します。正規のパッケージが持つ設定として不要と判断した場合は、次のコマンドで全Capabilityを剥奪できます。
sudo setcap -r /path/to/ファイル実行後にもう一度getcapで同じパスを調べ、何も表示されなくなっていれば剥奪成功です。元の設定に戻したい場合はパッケージを再インストールすれば、インストール時のスクリプト（postinst）が正しいCapabilityを再設定してくれます。
定期点検を仕組み化する：差分で「新規追加」だけ検知する
1回きりの点検では「昔からこの状態だったのか、最近仕込まれたのか」が分かりません。今の状態をファイルに保存しておき、次回以降は差分だけを見る運用にすると、少ない手間で新規の変化に気づけます。
# 初回：現在の状態を保存（自分のホームディレクトリに書くだけなのでsudoの影響は読み取りのみ）
sudo find / -xdev -perm -4000 -type f 2>/dev/null | sort > ~/suid_baseline.txt
# 次回以降：保存済みの状態と比較
sudo find / -xdev -perm -4000 -type f 2>/dev/null | sort | diff ~/suid_baseline.txt -diffの出力で行頭が>のものは「保存時になく、今回新たに出現したファイル」なので最優先で確認してください。行頭<は「以前あったが今はない」で、パッケージ更新でSUIDが外れたようなケースが多く緊急度は低めです。getcap側も同じ要領で~/getcap_baseline.txtを作っておくとよいでしょう。手動実行が面倒であれば、月次のcronやsystemdタイマーで結果をメールやファイルに出力する運用に発展させられます。
あわせて、SSHの不正ログイン試行を突き合わせるSSHログとauthorized_keys突合2026年8月版や、隣接する権限昇格の穴を塞ぐpkexec/polkit権限昇格チェック2026年8月版も合わせて点検すると、権限まわりの死角をより広くカバーできます。
まとめ
find / -xdev -perm -4000 -type fでSUIDバイナリを、getcap -r /でCapability付きバイナリを、どちらも読み取り専用のコマンドだけで洗い出せます。判定基準は「標準的なパスにあるか」「見覚えのある名前か」の2点で十分です。不審なファイルが見つかったらdpkg -Sで所属を確認し、不要ならSUIDはchmod u-s、Capabilityはsetcap -rで剥奪できます。どちらも1コマンドで元に戻せる操作なので、まずは今の状態を保存しておき、月イチの差分チェックから始めてみてください。