- Landlock は、アプリケーションがアクセス可能なリソースを明示的に宣言し、カーネルレベルで自己サンドボックス化を実行する Linux セキュリティ API です
- 既存の SELinux や AppArmor よりもシンプルで、開発者権限なしでランタイムにポリシーを作成・適用できます
- ポリシーはアクセス可能なファイル・ディレクトリ・ポートなどを**明示的な許可リスト（allowlist）**として定義し、階層的な制限により段階的なセキュリティ強化が可能です
- Rust、Go、Haskell などでバインディングが提供されており、GUI アプリ、サーバー、デスクトッププロセスなどさまざまな環境できめ細かなアクセス制御を実装できます
- Linux のセキュリティエコシステムで、シンプルで実用的な無権限サンドボックスツールとして、今後 Linux デスクトップセキュリティ強化の中核要素として注目されています
Landlock の概要
- Landlock は、Linux アプリケーションがアクセス可能なリソースを明示的に宣言することを要求する API
- OpenBSD の
unveil() や pledge() の概念に近く、「必要なリソースだけを許可し、残りはブロックする」という原則に基づいています
- 既存の Linux セキュリティメカニズムより理解と統合が容易な開発者フレンドリーな防御層を提供します
- 目的はアクセス可能なリソースを明示することで Landlock の利用を促進することです
動作方式
- Linux Security Module（LSM） 形式として、Linux 5.13 から利用可能です
- SELinux や AppArmor と異なり、**プロセス単位の一時的制限（transient restriction）**を適用します
- ポリシーはランタイムで生成され、現在のスレッドと子プロセスにのみ適用され、プロセス終了時に消失します
- ポリシー構成要素
- Handled accesses: 制限する操作カテゴリ（例: ファイルシステムの読み取り/書き込み）
- Access grants: 許可するオブジェクトの明示的なリスト
- ポリシー例
/home/user 読み取り専用/tmp 読み書き- ポート
2222 のバインド許可
landlock_restrict_self() 呼び出し時、対象スレッドと子プロセスは永続的な制限領域に入ります
- 制限は解除不可で、最大 16 層（layer）まで重ねて適用可能
- 下位層はアクセスをさらに削減できますが、上位層で削除された権限は復元できません
- **非権限（unprivileged）**方式なので、一般アプリケーションでも自己サンドボックス化できます
- ABI バージョン管理により、旧カーネルでも可能な範囲で動作します
- Stackable LSM であり、SELinux や AppArmor と併用可能です
利用理由
- 予測可能なファイルアクセスパターンを持つアプリケーションに適しています
- 例: Web サーバーが
/var/www/html と /tmp のみアクセスするよう制限
- 管理者の介入やシステム全体の設定は不要で、コード内で直接ポリシーを定義できます
- 権限昇格なしで利用でき、ほとんどのプログラムに容易に統合可能です
- Rust、Go、Haskell 用バインディングがあり、
unveil スタイルのラッパープロジェクトも多数
- 公式 C ライブラリはまだありませんが、複数の非公式実装が利用できます
- Rust のサンプルコードでは
/usr、/etc、/dev が読み取り専用、/home、/tmp が読み書き可能に設定されています
Linux のサンドボックス化の現状と必要性
- Linux 利用の増加に伴い、デスクトップ向けマルウェアも増えています
- Linux の相対的な安全性は、構造的な強さというより市場シェアと技術的ハードルによるものです
- 一般的なディストリビューションの問題点
- 信頼されていないバイナリを実行できる
- インターネットからスクリプトを直接実行できる
- パスワードなしで sudo を使う
- 一般アプリケーションが
$HOME 内の機密ファイルにアクセスできる
- X11 環境でキー入力監視が可能
- 任意ポートへのバインドが可能
既存のセキュリティツールの限界
- Containerization（Docker、Podman）: サービス分離には適しているが、デスクトップアプリには不向き。
--privileged オプションで分離が無効化される事例があります
- Flatpak / Snap: GUI アプリには適しているが権限範囲が広すぎ、CLI ツールには不適切です
- Firejail: アプリごとのプロファイルが必要で、毎回明示的な呼び出しが必要
開発者視点での既存のメカニズム
- seccomp: 強力だが設定が複雑で、ブラックリスト方式は脆弱です
- SELinux: 強力だが複雑で、管理者ポリシーが必要。多くのディストリビューションでデフォルト無効
- AppArmor: SELinux よりはシンプルだが、なお管理者プロファイルが必要で、一部のディストリビューションでは無効
Landlock の利点まとめ
- 非権限、アプリケーション中心、統合しやすい、デフォルト拒否（deny-by-default）
- Linux 5.13 以降で広くサポートされ、下位/上位互換性の維持
- 完璧ではないものの、シンプルで独立した無権限サンドボックスツールとしてその空白を埋める
Landlock の適用可能性
- 高権限デーモンプロセスの長時間実行時、Landlock によりアクセス範囲を制限できます
- PDF リーダー、画像ビューア、Web ブラウザ、ワードプロセッサなどは開いたファイルのみアクセスするよう制限可能
- FTP / HTTP サーバーも必要なファイルだけにアクセスするよう設定できます
- 例: nginx が root で実行されていても、攻撃者がシェルを奪取してもポリシー外のファイルにはアクセスできません
- Supervisor 提案が導入されれば、Linux デスクトップに Android 風の権限システムを実装できます
- GUI と権限保存システムを組み合わせれば、より安全なユーザーエクスペリエンスが実現できます
Landlock の進行中機能開発
- Supervise Mode: ユーザー空間でアクセス許可/拒否を対話的に決定し、Android の権限プロンプトに近い挙動
- Socket Restrictions: プロセスが使えるソケット種類とポートをきめ細かく制御
- LANDLOCK_RESTRICT_SELF_TSYNC: 制限をプロセス内のすべてのスレッドに伝播
- LANDLOCK_ADD_RULE_QUIET: 特定オブジェクトの監査ログメッセージを抑止
- LANDLOCK_ADD_RULE_NO_INHERIT: 親ディレクトリ権限が子へ継承されないようにし、ファイルシステム制御を細分化
要約
- Landlock はシンプルで非権限ベースのデフォルト拒否型サンドボックスメカニズム
- 理解と統合が容易で、Linux デスクトップおよびアプリケーションセキュリティ向上に大きな潜在力を持っています
- 開発者はアプリケーションに Landlock を直接適用して、セキュリティレベルを強化できます
1件のコメント
Hacker Newsの意見
Cで簡単なプログラムを書き、特定の1つのポートだけを受信できるようにして、その他のネットワーク接続はすべて遮断した
sandboxer.cの例を参考にし、ファイルアクセス制限には手を付けず、ネットワークだけを制御しているdmesgに遮断された接続が表示されるが、おそらく audit機能 のおかげだと思うこのツールは 非特権ユーザーモード で動作し、コンテナ内でもファイアウォール設定なしでうまく動く
ただし、悪意あるプログラムを完全に防ぐ用途には向いていないと思う
issue #28 と 関連メールスレッドを見ると、サンドボックス規則が 存在しないディレクトリ を参照できないという問題がある
たとえば
~/.sshがまだ存在しないときに規則を追加すると、あとからディレクトリが作成されてもアクセスは遮断されないつまり、セキュリティ上の穴が生じる可能性がある
最小権限で実行しようとするとかなり厄介だ
「Microlandia」は動かないが、他のUnityゲームは問題なく動く
Landlockベースのツールがもっと増えて、こうした作業が簡単になることを期待している
CRIは独自インターフェースを定義しようとしているようだが、カーネル対応より常に遅れざるを得ない
ほとんどのインフラ担当者はアプリごとにサンドボックスポリシーを保守しないと思う
アプリケーションが直接Landlockを使うほうが現実的だと考える
ランタイムがシステムコールをそのまま通す場合、アプリが自分でロックダウンすることを 信頼しなければならない問題 が生じると説明している
社内では似たようなAPIを使って 重要プロセス管理 を行っている
こうした研究は規制産業にも大いに役立つはずだ
カーネル機能なら当然C APIが先にあるはずなのに、なぜないのか気になる
libcはその上に載る層にすぎず、今でも多くのsyscallにはlibcのラッパーが存在しない
自分でヘッダーを作って
_syscallNマクロで呼び出すこともできるlandbox のような簡単なラッパーを使えばよく、
RustやGoもC FFIを公開できる
カーネルの sandboxer.c の例 を参考にすれば十分だ
Landlockとは別物だが、補完的に使える
/sys設定の代わりに 新しいsyscall を追加したのは興味深いおそらく 非特権の原則 のためだろう
seccompでLandlockのsyscallを遮断できるのかも気になる
古いseccompポリシーにLandlockの番号が含まれていなければ、SIGSYSが発生するのではないか?
ファイルシステムベースのAPIには footgun が多く、dirfdベースのアクセス制御にはsyscallのほうが適している
うまく書かれたseccompフィルタは -ENOSYS を返すため、単に「未対応」のように見える
Landlockは既存の権限をさらに制限するだけで、新たな権限を与えるわけではないからだ
Macから離れてLinuxへ完全移行する準備をしていて、malware対策 にLandlockがどう役立つのか気になる
たとえば
~/.sshへのアクセスを自動で拒否する環境を作りたいまた、これで アプリランチャー を作れるのかも知りたい
アプリが自ら不要な権限を制限し、攻撃者がシステムを掌握できないようにするためのものだ
~/.sshへのアクセス拒否のような用途には、AppArmor や SELinux のようなMACモデルが必要だLandlockはアプリ自身、あるいは子プロセスを制限するときに有用だ
たとえばnpmがpost-installスクリプトをビルドディレクトリ内だけに制限するような使い方だ
OpenBSDの pledge のように、アプリ開発者が直接使うAPIだ
ただしLinuxはエコシステムが分散しているため、普及は遅いだろう
それまでは ラッパーやランチャー の形で使うのが現実的だ
結局のところ、プログラムが自分の権限を把握している場合 にしか効果がない
アプリが実行初期に必要なリソースだけをホワイトリスト指定し、それ以外を遮断する
悪意あるプログラム対策ではなく、自己プロセス保護 のためのものだ
標準ライブラリにはすでにsyscallがあるのに、わざわざ別ライブラリが必要なのか?
man7ドキュメント も存在する
単に 抽象化レイヤー を求めているという意味なのだろうか
glibcがまだLandlockインターフェースを提供していないのは意外だ
おそらく 非Linux互換性 の問題が理由だと思われる