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