/ usr / sbinなどの実行可能ファイルがrootによって書き込み可能になるのはなぜですか？

バイナリコンパイルされたファイル（など/usr/sbin）にrootユーザーの書き込み権限がある理由を説明してください。

私にとっては、これはコンパイルされています。つまり、直接書き込みは何の役にも立たず、ファイルを何らかのセキュリティ問題にさらす可能性があります。

スクリプト（bashファイルなど）は基本的にテキストファイルであるため、書き込み可能かもしれませんが、筆者が知っている限り、実際には書き込みが必要ないコンパイルされたファイルでも同じです。

ご意見をお寄せいただきありがとうございます。

— t1m0th33
ソース

明確にするために、ユーザーrootがバイナリファイルへの書き込み許可を持っている理由を疑問に思っていますか？それ以外の場合は、そのパッケージをアップグレードするときに役立ちます。

— エリックルヌーフ

皮肉なことに、通常、ディスク上で直接書き込み/編集を行うファイルはバイナリファイルだけです。テキストの変更にはファイルへの書き込みではなく、ファイルの途中で余分なバイトを追加したり、ファイルの途中でバイトを削除したりするため、スクリプトのようなテキストファイルではできません。これはfseek fwriteでは不可能です。そのため、テキストファイルの場合は通常、RAMに読み込んでから古いファイルを削除し、RAMの内容をディスクに書き込みます（つまり、上書きします）。また、実行可能ファイルをインストール、移動、または置換するときは、ディスクへの書き込みを行うため、書き込み権限が必要です。

— スリーブマン

@slebetman：テキストファイルを直接編集できます。たとえば、ファイルを開いて拡張し、メモリマップし、memmove()最後の部分を最後に移動して穴を開け、新しいテキストを穴に挿入します。または、一連のpread()/ pwrite()を使用して同じことを行うこともできます。

— ザンリンクス

@EricRenouf実際には、バイナリファイルへの書き込み権限は、それを含むパッケージをアップグレードするために必要ではありません。パッケージのアップグレード時に、古いバイナリは書き込まれません。実際、バイナリが現在実行中の場合、これは不可能です（検索ETXTBSY）。代わりに、古いバイナリが削除され、新しいバイナリが同じ名前の新しいファイルに書き込まれます。ファイルを削除するには、それらを含むディレクトリ（つまり、/usr/sbin/）に対する書き込み権限のみが必要です。

— -marcelm

@marcelm：厳密に言うと、単にfseekとwriteを使用しているのではなく、残りをRAMにバッファリングしています。残りを別のファイルにバッファリングすることもできます。または、新しいファイルに新しいコンテンツを書き込むことができます。いずれも、何らかの大きなバッファなしでテキストファイルを拡張できます。

— スリーブマン

/bin（または実行可能ファイルが保存されている他の標準ディレクトリ）のファイルがrootによって書き込み可能かどうかは、実際には関係ありません。私が使用しているLinuxサーバーでは、rootで書き込み可能ですが、私のOpenBSDマシンではそうではありません。

グループまたは「その他」によって書き込み可能でない限り！

次のようなセキュリティ問題はありません。

-rwxr-xr-x 1 root root 126584 Feb 18  2016 /bin/ls

誰かがそれを上書きしたい場合、彼らはルートである必要がrootあり、もし彼らがそれを上書きするなら、彼らはどちらかです

新しいバージョンのインストール、または
不器用、または
既にルート権限を持つ攻撃者。

考慮すべきもう1つのことは、rootが書き込み保護されているかどうかに関係なく、ファイルに書き込むことができるということです。

「スクリプト」はバイナリファイルと同じくらい実行可能ファイルであることに注意してください。スクリプトは「テキストファイルであるため」書き込み可能である必要はありません。どちらかといえば、おそらく同じディレクトリ内の他の実行可能ファイルと同じ許可を持っているだけです。

すべての権限を今すぐ変更しないでください！それはあらゆる種類の大混乱を引き起こし、パーミッションが適切に設定されていることを検証するかもしれないパッケージマネージャーを混乱させる可能性があります。また、セキュリティが重要なアプリケーションで誤って権限を誤って変更した場合、システムが脆弱になる可能性があります。

本当に奇妙に見えるものを見つけない限り、実行可能ファイルのアクセス許可が正しく設定されていると仮定してください。

コメントとチャットから、いくつかの歴史への呼びかけがありました。

Linux上のバイナリのパーミッションの履歴は、私が知っていることではありません。彼らは単にディレクトリから、または単にumaskLinux のデフォルトからパーミッションを継承したと推測されるかもしれませんが、私は本当に知りません。

私が知っていることは、OpenBSDはデフォルトで許可モード555でベースシステム^1にバイナリをインストールすることです（-r-xr-xr-x）。これは、555に/usr/share/mk/bsd.own.mk設定さBINMODEれるMakefileフラグメントで指定されます（既に設定されている場合を除く）。これは、後にで実行可能ファイルをインストールするときに使用さmake buildれ/usr/srcます。

私は見ていたこのファイルの注釈付きのCVSログを、そしてそれは、1995年にはNetBSDから輸入されたため、ファイルに次の行が変更されていないことがわかりました。

NetBSDでは、1993年に555に設定されたファイルが最初にCVSに入れられましたBINMODE。

FreeBSDプロジェクトは少なくとも1994年以来、 NetBSDとまったく同じファイルを使用しているようであり、後のコミットでコミットメッセージに古いファイルがBerkeley Software Distributionの4.4BSDリリースのものであるというヒントが追加されます。

それを超えて、バークレーのCSRGはソースをSCCSに保持しましたが、そのリポジトリはGitHub ^2のGit形式で利用可能です。ここでフォレンジック処理を行っているファイルは、1990年にキースボスティック（または彼に近い人物）によってコミットされたようです。

それがその物語です。理由が必要な場合は、キースに尋ねる必要があります。「これは555である必要があります...」という変更に対するコミットメッセージを見たいと思っていましたが、そうではありません。

¹ _{BSDシステムは、Linuxよりも「ベースシステム」と「サードパーティパッケージ」（ポート/パッケージ）により厳密に区分されています。基本システムは、オペレーティングシステムを実行するための完全な機能セットを提供する一貫したユニットであり、ポートまたはパッケージは「ローカルソフトウェア」と見なされ、の下にインストールされ/usr/localます。}

² _{70年代以降のUnixリリースのより包括的なGitHubリポジトリも利用可能です。}

— クサラナナンダ
ソース

お返事ありがとうございます。書き込み権限は、rootユーザーであるかどうかは実際には関係ないため、正常です（彼は何でもできます）。しかし、実際には問題ではないので、最初から同じである場合は書き込み許可を付けないのはなぜですか？それはarbitrary意的な決定ですか？

— t1m0th33

@ t1m0th33それは誰かが行ったarbitrary意的な決定かもしれません、はい。私が言ったように、私のOpenBSDシステムでは、これらの場所にあるファイルはによって書き込めませんroot。

— クサラナナンダ

私はそれが誰かによる意識的な決定だとは思わない。パッケージマネージャーは、デフォルトで、ビルドプロセス中に最終的に許可ビットでファイルをインストールします。リンカーを構築する際、パーミッション755でファイルを作成しました。これは、777からumaskを引くと得られるものであり、構築中にumaskルート（OSベンダーのビルドマシン上）が022であったため、022は全員のデフォルトのumaskであり、ルートの場合は222であるため、余分な作業は無意味です。

— ヘニングマックホルム

「今すぐすべての権限を変更しないでください」の+1。私は、Ubuntuでユーザーがやを行っchmod -R たところにUsk Ubuntuでそのような多くの質問を見て、驚き-彼らは働いていないか、他の何かが働いていません。/usr/varsudo

— セルギーKolodyazhnyy

歴史的には、rootに対する書き込み許可がない場合は効果がありません（rootは何もchmodできず、とにかくrootはオープンまたは書き込み時にEPERMを取得しないため）。rootが実際に制限されるようになったために、この555が始まったのだろうか（securelevelsが最初に現れたのは4.4BSDまたは386BSD / NetBSDの初期とほぼ同時ですか？）