システム化された動的ユーザーとユーザー

システム化された動的ユーザーとユーザー

root権限なしでプロセスを実行するには、DynamicUser =を使用するか、systemdでUser =を持つ静的ユーザーを使用できます。 DynamicUserの詳細な説明は、次のブログ記事にあります。http://0pointer.net/blog/dynamic-users-with-systemd.html

しかし、どちらがより安全ですか? DynamicUserが動的ユーザーを使用し、ユーザーがシステムユーザーを必要とすることに加えて、DynamicUserとUserの正確な違いは何ですか?

答え1

DynamicUserより安全な理由は次のとおりです。

  • ProtectSystem=strict/dev/:APIファイルシステムサブツリーを/proc/除いて、ファイルシステム階層全体は読み取り専用としてマウントされます/sys/
  • ProtectHome=read-only:ディレクトリ/home/とこのユニットを呼び出すプロセスは読み取り専用に設定されています/root/run/user
  • PrivateTmp=yes:実行中のプロセスの新しいファイルシステム名前空間を設定し、名前空間外のプロセスで共有されていないプライベートディレクトリ/tmp/とディレクトリをマウントします。/var/tmp/これは一時ファイル処理へのアクセスを保護するのに役立ちますが、プロセス間の共有は/tmp/不可能です/var/tmp/。この機能を有効にすると、サービスが停止した後、そのディレクトリからサービスによって生成されたすべての一時ファイルが削除されます。
  • RemoveIPC=yes:デバイスのユーザーおよびグループプロセスが所有するすべてのSystem VおよびPOSIX IPCオブジェクトは、デバイスが停止したときに削除されたかのように実行されます。

これらの設定を使用するときは、明示的に設定してこれらの設定を模倣することで、効果User=的に同じ保護を得ることができます。

より良いアプローチDynamicUser=は、サービスインスタンスを作成することです。あなたfoo.socketがどんな用途にも使用すると仮定してくださいAccept=yes。この場合、誰かがソケットに接続するたびにfoo@%i.service新しいソケットが作成されます。各インスタンスには、DynamicUser=使用されると/tmp共有される独自の名前空間とディレクトリがあります。User=

答え2

User設定してもoptionsの指定に邪魔になることはありませんDynamicUser=true

~によると文書User=強調):

指定されたユーザー/グループ名で使用時DynamicUser=サービス開始時に動的に割り当てられ、サービス終了時に解除されます。- 静的に割り当てられていない場合(下記参照)。使用しない場合、DynamicUser=指定されたユーザーとグループは、サービスの開始前にユーザーデータベースに静的に作成する必要があります。たとえば、ブートまたはパッケージのインストール時に適用されるsysusers.d(5)ツールを使用します。ユーザーが存在しない場合、プログラム呼び出しは失敗します。

DynamicUser=しかしに制限がある。文書:

...指定され、その名前の静的グループが存在する場合は、User=その名前を持つ静的ユーザーがすでに存在している必要があります。同様にGroup=指定し、その名前の静的ユーザーが存在する場合は、その名前の静的グループがすでに存在している必要があります。

デフォルトでは、これはオプションを使用してカスタマイズを指定し、ユーザーと同じ名前のグループが存在する場合は、ユーザー自体をシステムに作成する必要があることを意味しUserますDynamicUser。カスタマイズを指定する場合も同様ですGroup

前任者。を指定User=dockerし、dockerシステムにグループが存在する場合、そのdocker名前を使用するにはユーザーもすでに存在する必要があります。

上記の制限を解決する方法は、既定でシステムにすでに存在するユーザーやグループを使用しないようにすることです。


長すぎます。

あなたの質問に答えるとセキュリティが向上しますが、使用するかどうかについての質問でDymamicUser=はありません。 Aには実際のユーザーが接続できますが、そのユーザーはUserDynamicUserDynamicUserUserいいえはい次へ追加または/etc/passwd/etc/group

源泉:

関連情報