一部のアプリケーションでグループとユーザーを作成することが推奨されるのはなぜですか?


11

ほとんどの場合、ソースからプログラムをインストールするときは、新しいユーザーと新しいグループを/usr/local/<myapp>作成し、最近作成したユーザーとグループに所有権を与えることをお勧めします。

  • なぜそのような実践は良い習慣と考えられているのですか?

  • 何が改善されますか?

例:MySQLデータベースサーバーのmysql user / mysqlグループ。

回答:


11

アプリケーションごとではなく、サービスごとに1人のユーザーとグループを作成するのが習慣です。つまり、ローカルユーザーが実行するプログラムは、root以外のユーザーとしてインストールする必要はありません。これはデーモンであり、バックグラウンドで実行されているプログラムであり、ネットワークまたはその他の通信手段を介して送信される要求を実行し、専用ユーザーとして実行する必要があります。

デーモンは専用のユーザーとして実行されるため、(バグが原因で、おそらく攻撃者によって引き起こされた)動作に問題がある場合、デーモンが実行できるダメージは限られています。影響を受けるのはデーモンのデータファイルだけです(攻撃者がローカルルートホールを見つけられない限り) 、発生する可能性があります)。たとえば、データベースデーモンmysqldは専用のユーザーおよびグループとして実行されmysql:mysql、データベース(/var/lib/mysql/*)のデータファイルはに属しますmysql:mysql

デーモン実行可能ファイルと、使用されているがデーモンによって変更されるべきではないその他の静的データおよび構成ファイルは、専用ユーザーに属してはいけません。root:rootほとんどのプログラムおよび構成ファイルと同様に、それらはが所有する必要があります。mysqldプロセスには、ビジネスの上書きを持っていない/usr/sbin/mysqldか、/etc/mysql/my.cnfこれらのファイルはに属していなければなりませんので、mysqlまたはユーザーによって書き込み可能でmysql、ユーザーまたはmysqlグループ。一部のファイルをデーモンと管理者のみが読み取り可能にする必要がある場合、それらのファイルはユーザーrootと専用グループが所有し、モード0640(rw-r-----)である必要があります。

によって所有できない実行可能ファイルの特別なカテゴリはroot:root、ユーザーによって呼び出されたが、追加の特権で実行する必要があるプログラムです。これらの実行可能ファイルをrootとして(少なくとも部分的に)実行する必要がある場合は、setuid rootにする必要があります。その場合、実行可能ファイルはモード4755(rwsr-xr-x)を持っている必要があります。プログラムがrootではなく追加の特権を必要とする場合は、プログラムをsetgidにして、追加の特権がユーザーではなくグループを介して提供されるようにする必要があります。実行可能ファイルのモードは2755(rwxr-sr-x)になります。理由は2つあります。

  • 実行可能ファイル自体の変更を許可しないでください。ユーザーが脆弱性を悪用した場合、プログラムが使用するデータファイルを変更できますが、プログラムを実行している他のユーザーを攻撃するためにトロイの木馬を実行可能ファイルに挿入できません。。
  • 実行可能ファイルのデータファイルはグループに属しています。setuidプログラムは、ユーザーと対話するために実際のユーザー(プログラムを呼び出したユーザー)と、プライベートデータファイルにアクセスするために有効なユーザー(プログラムを実行しているユーザー)を切り替える必要があります(その理由)追加の特権を持っている)。setgidプログラムはさらに、グループにのみアクセス可能なユーザーごとのデータを分離できます(たとえば、ルートとプログラムのグループにのみアクセス可能なディレクトリにユーザーが所有するファイルを格納することにより)。

3

これは一般的なアプリケーションではなく、これが目的のデーモンです。その理由は、デーモンがrootの代わりに非特権ユーザーとして実行できるため、セキュリティの脆弱性があり、侵害された場合、実行可能な被害はユーザーがアクセスできる領域にのみ含まれるためです。


1

これが良い習慣と考えられている理由は、システムの他のユーザーが特定のアプリケーションのデータと構成ファイルを上書きしないようにするためです。

例としてmysql/ mysqlデータベースを破損からアプリケーションAPIを使用していないのMySQLデータベースファイルを防ぎ、誰のためのストレージの所有者です。さらに、ユーザーmysqlは通常、実際のシェルを持っていないため、そのユーザーとしてログインすることはできません。


重要なポイントを見逃しました。それは、アプリケーションが実行されているユーザーとグループの問題であり、実行可能ファイルとその他の静的ファイルはrootが所有する必要があるということです。
Gilles 'SO-悪をやめる

@Gillesそれらはrootが所有でき、ディストリビューション経由でインストールされるほとんどのアプリケーションは所有しますが、そうである必要はなく、そうである必要もありません。実際のところ、Ubuntuで/usr/bin/at所有さdaemon/daemonれています
Karlson 2012年

1
atデーモンではありません。プライベートファイルを介しdaemonatdデーモンと通信できるように、それはsetuid です。
Gilles 'SO-悪をやめなさい'

1

新しくインストールされたデーモンの新しいグループ/ユーザーを作成すると、セキュリティが向上します。このようなユーザーの下でサーバープロセスを実行すると、そのユーザーのアクセス権に制限されます。比較すると、それがrootとして実行されると、すべてを実行できます。

この違いは、デーモンが正しく設定されていない場合や、セキュリティ関連のバグが含まれている場合に重要です。

質問の2番目の部分、つまり/usr/local所有権に関する部分の意味がわかりません。一般にX、セキュリティ上の理由でデーモンを実行している同じユーザーがバイナリを含むディレクトリを所有していることは意味がありません(その場合、エクスプロイトの場合にそれらが変更される可能性があるためです)。ただし、デーモンが動作するデータファイルのあるディレクトリには、アクセスできる必要がありXます。これを設定する最も簡単な方法Xは、データディレクトリ/ファイルの所有者を作成することです。

独自の特別なユーザーでデーモンを実行することは、セキュリティ手法の1つにすぎません。他の方法としては、ある種の「chroot」や、強制アクセス制御(MAC)システム(SELinuxなど)の使用があります。


1

これはセキュリティ上の考慮事項です。これは、デーモンアプリケーションに侵入したユーザーが実行できるダメージを制限します。ユーザーアプリケーションは通常、などの標準ユーザーIDが所有していrootます。

Webサーバー、メールサーバー、データベースがすべて同じユーザーとして実行されている場合、それらのセキュリティが侵害されやすくなります。それらのいずれかにシステムアクセスを許可するバグまたは設定ミスがある場合、そのアクセスを使用して3つのアプリケーションすべてにアクセスできます。

推奨されているように、それらすべてが個別のアカウントを持っている場合、侵害されたアプリケーションのみにアクセスできる可能性があります。もう一方のパブリック構成の詳細は読み取られる可能性がありますが、変更を加えることはできません。

多くのデーモンでは、ユーザーがファイルをアップロードおよびダウンロードできるほか、他のデーモンの構成に対してユーザーが実行できないようにしたいことができます。各アプリケーションに独自のユーザーIDとグループがある場合、デーモンを保護する方が簡単です。

デーモン固有のグループがあると、ファイルとディレクトリへの読み取り専用の安全なアクセスをデーモンに安全に許可することがより簡単になります。ファイルまたはディレクトリが別のユーザーによって所有されているが、デーモングループに属している場合、通常は読み取り専用でアクセスできます。アクセス許可は、findなどのツールを使用して簡単に確認および修正できます。


重要なポイントを見逃しました。それは、アプリケーションが実行されているユーザーとグループの問題であり、実行可能ファイルとその他の静的ファイルはrootが所有する必要があるということです。
Gilles 'SO-悪をやめる

@Gilles:それに応じて注記および編集されています。
BillThor 2012年
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.