☰

仮想マシン/オペレーティングシステム

tag-icon • tag-icon permissions non-root-user jails
仮想マシン/オペレーティングシステム

私がルートしたら、単にダミーユーザー/グループを作成し、それに応じてファイル権限を設定し、そのユーザーとしてプロセスを実行できます。しかし、私はそうではありません。ルートなしでこれを達成する方法はありますか？

ベストアンサー1

同様の質問、より注目すべき答え：

メモ:そこにある答えのいくつかは、ここでまだ言及されていない特定の解決策を指しています。

実際にはさまざまな実装を備えたかなり多くの刑務所ツールがありますが、その多くは設計上安全ではないか（ベースなど）、不完全です（例：fakerootベース）。LD_PRELOADfakeroot-ngptracechrootplashfakechroot 警告ラベル）。

これは単なる例です。 2つの機能（「信頼できますか？」、「設定するにはルートが必要ですか？」）を並べて配置したかったです。オペレーティングシステムレベルの仮想化の実装。

一般に、ここへの答えは、説明されているすべての可能性とそれ以上のものを網羅しています。

仮想マシン/オペレーティングシステム

カーネル拡張 (例: SELinux)

  • （ここのコメントに記載）

chroot

chrootChrootベースのヘルパー（ただし、rootが必要なのでsetUIDルートである必要があります。そうしないと、chroot孤立した名前空間で動作する可能性があります。以下を参照）

[彼らについてもっと教えてください！ ]

既知のchrootベースの分離ツール：

道

もう一つの信頼できる隔離ソリューション（その他seccompに基づいてptrace) マンページに記載されているように転送し、完全なシステムコールをブロックします。fakeroot-ng:

以前の実装とは異なり、fakeroot-ngは、追跡されたプロセスがfakeroot-ngの「サービス」を使用するかどうかを選択できないようにする技術を使用します。プログラムの静的コンパイル、カーネルへの直接呼び出し、および独自のアドレス空間操作は、すべてLD_PRELOADベースのプロセス制御をバイパスするために使用できる技術であり、fakeroot-ngには適用されません。理論的には、fakeroot-ngは追跡プロセスを完全に制御できるように構成できます。

理論的には可能ですが、まだ実装されていません。 Fakeroot-ngは追跡されたプロセスに対して特定の「うまく機能する」仮定を行います。これらの仮定を破るプロセスは完全に逃げることはありませんが、fakerootがそのプロセスに課すいくつかの「偽の」環境をバイパスする可能性があります。したがって、fakeroot-ngをセキュリティツールとして使用しないことを強く警告します。プロセスが意図的に（偶然ではなく）fakeroot-ng制御から外れる可能性があると主張するバグレポートは、「バグではない」で閉じられるか、低い優先順位で表示されます。

このポリシーは将来見直される可能性があります。しかし今は警告を受けました。

しかし、読んだように、fakeroot-ngこの機能自体はこの目的のために設計されていません。

seccomp（しかし、なぜ彼らがChromiumのベースアプローチではなくptraceベースアプローチを使用することを選んだのか疑問に思う...）

上記以外のツールの場合ジョルディ私自身のためにHaskellで制御プログラムを書くのが好きだからです。

既知のptraceベースの分離ツール：

セキュリティコンピューティング

分離を達成する既知の方法の１つは、以下の通りである。Google Chromiumで使用されるseccompサンドボックス方式。しかし、このアプローチは、いくつかの（許可された）「傍受された」ファイルアクセスおよび他のシステムコールを処理するヘルパープログラムを作成すると仮定します。もちろん、システムコールを「傍受」ヘルパープログラムにリダイレクトする努力もあります。おそらく、これは制御されたプロセスのコードで傍受されるシステムコールを置き換えることを意味するかもしれません。したがって、興味があれば、私の答えだけでなく詳細を読むことをお勧めします。

追加の関連情報（Wikipediaを参照）：

（Chromiumの外で一般的なソリューションを探している人なら、seccompこの最後のものは興味深いようです。 "seccomp-nurse"の作者にも読めるブログ記事があります。サンドボックスソリューションとしてのSECCOMP？.)

このアプローチに関するガイダンスは、以下で提供されます。「seccomp-nurses」プロジェクト:

                      ここに画像の説明を入力してください。

将来、Linuxに「柔軟な」seccompは可能ですか？

2009年にも登場Linuxカーネルパッチのヒントこれseccompにより、モデルの柔軟性が向上し、「現在私たちが必要とする多くの曲芸を避けることができます」。 （「奴隷」とは、刑務所に閉じ込められたプロセスに代わって潜在的に無害なシステムコールを多く実行し、刑務所に閉じ込められたプロセス内で潜在的に無実のシステムコールを置き換える必要があるヘルパーの作成の複雑さを意味します。）LWN 記事この時点までに作成：

1つの提案は、seccompに新しい「モード」を追加することでした。 APIは、異なるアプリケーションが異なるセキュリティ要件を持つ可能性があるという考えで設計されています。これには、適用されるべき制限を指定する「モード」値が含まれています。オリジナルモードのみが実装されていますが、他のモードももちろん追加できます。起動したプロセスで許可されているシステムコールを指定できる新しいモードを作成すると、Chromeサンドボックスなどの状況でツールがより便利になります。

Adam Langley（また、Google出身）はこれを達成するためのパッチをリリースしました。新しい「モード2」実装では、アクセス可能なシステムコールを記述するビットマスクを許可します。これらのいずれかがprctl（）の場合、サンドボックスコードは独自のシステムコールをさらに制限できます（ただし、拒否されたシステムコールへのアクセスは復元できません）。全体的に、これはサンドボックス開発者の生活をより簡単にするための合理的なソリューションのようです。

つまり、議論が別の可能性に移ったため、このコードは決してマージされない可能性があります。

この「柔軟なseccomp」は、Linuxが複雑なヘルパーを書くことなく、オペレーティングシステムに必要な機能を提供するのに近づくようにします。

（本質的にこの回答と内容が同じブログ投稿：http://geofft.mit.edu/blog/sipb/33.)

ネームスペース( unshare)

名前空間（unshareベースソリューション) - ここでは言及されていません。共有マウントポイントのキャンセル（FUSE と組み合わせる？） 信頼できないプロセスへのファイルシステムへのアクセスを制限したい場合は、作業ソリューションの一部である可能性があります。

実装が完了すると、名前空間に関する追加情報が提供されます（この分離技術はnmeでも知られています）。「Linuxコンテナ」または「LXC」、そうではありませんか？ ..):

「名前空間の全体的な目標の1つは、（他の目的の中でも）軽量仮想化ツールであるコンテナの実装をサポートすることです。」。

新しいユーザーネームスペースを作成することで、「プロセスはユーザーネームスペースの外側には権限のない一般ユーザーIDを持つことができ、ネームスペース内にはユーザーID 0を持つことができます。ユーザーの名前空間はありますが、名前空間の外部操作に対する権限はありません。

これを行う実際の作業コマンドについては、ここの回答を参照してください。

そして特別なユーザースペースプログラミング/コンパイル

しかし、もちろん、必要な「刑務所」の保証はユーザースペース（この機能には追加のオペレーティングシステムサポートは必要ありません。;おそらくこれがまさにこの機能が最初にOSデザインに含まれていない理由です。）多少複雑な問題があります。

そこに言及されているptrace-またはseccompサンドボックスは、「ブラックボックス」、つまり任意のUnixプログラムで処理される他のプロセスを制御できるサンドボックスヘルパーを作成することによって達成される保証のいくつかのバリエーションと考えることができます。

別のアプローチは、無効にする必要がある効果を考慮するプログラミング技術を使用することです。 （その後、プログラムはユーザーが作成する必要があり、これ以上ブラックボックスではありません。）たとえば、次のようにします。純粋なプログラミング言語（これにより、副作用なしにプログラミングされます。）ハスケルプログラムのすべての効果を明示的に書くことで、プログラマが許されない効果がないことを簡単に確認できます。

Javaなど他の言語でプログラムする人々のためのサンドボックス機能もあるようです。

このトピックに関する情報を蓄積する一部のページも回答で指摘されています。

おすすめ記事