一部のアプリケーションでグループとユーザーを作成することが推奨されるのはなぜですか？
ほとんどの場合、ソースからプログラムをインストールするときは、新しいユーザーと新しいグループを作成し、/usr/local/<myapp>最近作成されたユーザーとグループの所有権。
なぜそのような実践は良い習慣と考えられているのですか？
何が改善されますか？
例：MySQLデータベースサーバーのmysql user/mysqlグループ。
アプリケーションごとではなく、サービスごとに1人のユーザーとグループを作成するのが習慣です。つまり、ローカルユーザーが実行するプログラムは、root以外のユーザーとしてインストールする必要はありません。それは daemons であり、バックグラウンドで実行され、ネットワークまたはその他の通信手段を介して送信される要求を実行するプログラムであり、専用ユーザーとして実行する必要があります。
デーモンは専用のユーザーとして実行されるため、（バグが原因で、おそらく攻撃者によって引き起こされた）動作に問題がある場合、デーモンが実行できるダメージは限られています。 、発生する可能性があります）。たとえば、データベースデーモン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プログラムはさらに、グループにのみアクセス可能なユーザーごとのデータを分離できます（たとえば、ユーザーが所有するファイルを、ルートとプログラムのグループにのみアクセス可能なディレクトリに格納することにより）。
これは一般的なアプリケーションではなく、これが目的のデーモンです。その理由は、デーモンがrootの代わりに非特権ユーザーとして実行できるため、セキュリティの脆弱性があり、侵害された場合、実行可能な被害はユーザーがアクセスできる領域にのみ含まれるためです。
これが良い習慣と考えられている理由は、システムの他のユーザーが特定のアプリケーションのデータと構成ファイルを上書きしないようにするためです。
例として、mysql/mysqlは、mysqlデータベースファイルのストレージの所有者であることにより、アプリケーションAPIを使用していないユーザーがデータベースを破損するのを防ぎます。さらに、ユーザーmysqlには通常、実際のシェルがないため、そのユーザーとしてログインすることはできません。
これはセキュリティ上の考慮事項です。これは、デーモンアプリケーションに侵入したユーザーが実行できる被害を制限します。ユーザーアプリケーションは通常、rootなどの標準ユーザーIDが所有しています。
Webサーバー、メールサーバー、データベースがすべて同じユーザーとして実行されている場合、それらのセキュリティが侵害されやすくなります。それらのいずれかにシステムアクセスを許可するバグまたは設定ミスがある場合、そのアクセスを使用して3つのアプリケーションすべてにアクセスできます。
推奨されているように、それらすべてが個別のアカウントを持っている場合、侵害されたアプリケーションのみにアクセスできる可能性があります。他のパブリック構成の詳細は読み取られる可能性がありますが、変更を加えることはできません。
多くのデーモンでは、ユーザーがファイルをアップロードおよびダウンロードできるほか、他のデーモンの構成に対してユーザーが実行できないようにしたいことを実行できます。各アプリケーションに独自のユーザーIDとグループがある場合、デーモンを保護する方が簡単です。
デーモン固有のグループがあると、ファイルとディレクトリへの読み取り専用の安全なアクセスをデーモンに安全に許可することがより簡単になります。ファイルまたはディレクトリが別のユーザーによって所有されているが、デーモングループに属している場合、通常は読み取り専用でアクセスできます。アクセス許可は、findなどのツールを使用して簡単に確認および修正できます。
新しくインストールされたデーモンに新しいグループ/ユーザーを作成すると、セキュリティが向上します。このようなユーザーの下でサーバープロセスを実行すると、そのユーザーのアクセス権に制限されます。比較すると、それがrootとして実行されると、すべてを実行できます。
この違いは、デーモンが正しく設定されていない場合や、セキュリティ関連のバグが含まれている場合に重要です。
質問の2番目の部分、つまり/usr/localの所有権に関する部分の意味がわかりません。一般に、セキュリティ上の理由でデーモンが実行されている同じユーザーXがバイナリを含むディレクトリを所有していることは意味がありません（その場合、エクスプロイトの場合にそれらを変更する可能性があるためです）。ただし、デーモンが動作するデータファイルのあるディレクトリにはXがアクセスできる必要があります。これを設定する最も簡単な方法は、Xをデータディレクトリ/ファイルの所有者にすることです。
独自の特別なユーザーの下でデーモンを実行することは、セキュリティ手法の1つにすぎません。他の方法としては、ある種の「chroot」や、強制アクセス制御（MAC）システム（SELinuxなど）の使用があります。