GNU/Linux >> Linux の 問題 >  >> Linux

プロジェクトのソース コードの内部サーバーで chmod -R 777 を使用しない理由は?

<ブロック引用>

しかし、少し考えてみたところ、内部サーバー上の共有実行可能コードに 777 パーミッションを持たせてはならない理由がわかりません。

すべてのユーザーを信頼するだけでなく、アクセス権を持つ「すべての人」がその制御を行う必要がある内部サーバーでは妥当かもしれませんが、そのサーバー上のすべてのプロセスも信頼しています。ウェブサーバー。 SSH サーバー。 DHCP クライアント。すべてのスケジュールされたタスクとすべてのサービス。 「nobody」および「nogroup」として実行されているプロセスでさえ。攻撃者がアクセス権を取得または拡大するために利用する可能性のあるあらゆる種類のプロセス。

なぜなら、あなたが内部開発でずさんになるなら、誰かが本番システムや顧客システムでずさんになるからです.なぜなら、「それが私たちが内部でそれを修正した方法だからです」.

攻撃者は、内部のみで重要でも保護されていない小さなシステムを見つけることに喜びを感じるため、書き込み可能な Web アプリケーション ファイルなどの弱点を見つけ、それらを使用してシステムに侵入し、それを利用してどこかに到達します。人々がそのシステムで使用するパスワードは、他のより価値のある内部システムでも機能するに違いありません。サーバー間でも同じ root パスワードを使用しているのではないでしょうか?見つけるのはいつも楽しいものです。


@gowenfawr に続いて、より良いチンパンジーを繁殖させること自体が目標です(ここで、あなたの企業文化について大雑把に推測してみます)

私のソフトウェア開発会社では、本番環境だけでなく、開発プロセスや企業の IT 全般においても、セキュリティ プラクティスの証拠を求める顧客が増加傾向にあるのを目にしています。以下の理由から、これは完全に妥当な要求です:

<オール>
  • 本番環境のセキュリティが不十分であると、データが危険にさらされます。参照:2017 年の Equifax 侵害。
  • 開発におけるずさんなセキュリティは、開発者がずさんな製品を書くことにつながります。実際には、セキュリティが重要であるという姿勢は、管理者が開発者にセキュリティ トレーニングを提供し、適切なコード レビューを行う時間を提供し、顧客の機能よりもセキュリティ上の欠陥を修正することを優先する意欲を持つ必要があります。このようなずさんな慣行を許すことは、企業文化がセキュリティを促進していない証拠です。
  • IT におけるずさんなセキュリティ プラクティスは、ネットワーク内のウイルスにつながり、コード内のウイルスにつながる可能性があります。誰かが電子的にバックアップ コード リポジトリに侵入し、最終的にメイン リポジトリにマージされることを期待して、悪意のあるコード変更を挿入した 2003 年の有名な Linux バックドアの試みをご覧ください。
  • これは、お客様に誇りを持って伝えられる決定ですか?

    結論: 最小特権の原則は、最も基本的なセキュア コーディングの原則の 1 つです。これは、ソフトウェア開発プロセスの一部であるべき考え方です。 「これが危険だと誰かが証明できるか」ではなく、「このようにセキュリティを弱める必要があるか」という質問です。ハッカーは常にあなたより賢いです。

    もちろん chmod 777 の場合 何らかの理由で必要な場合、それは最小の特権になり、ここで正当なセキュリティの議論が行われる可能性がありますが、そうではないようです。これはただの怠惰です。これでは、製品自体で最小権限の原則が守られているという確信が持てません。たとえば、データの保存方法、API 呼び出しから返される余分なデータの量、ログに記録される情報、または最小権限の原則が適用される場所などです。


    プログラムが書き込み権限を必要としない限り、あなたの同僚がなぜ chmod -R 777 /opt/path/to/shared/folder を使用したのか、私は混乱しています。 chmod -R 775 /opt/path/to/shared/folder のとき 読み取りと実行のアクセス許可を引き続き許可し、目的のアクセスを達成します。

    サーバーにアクセスできるのはチーム メンバーだけであり、チーム メンバーを信頼しているとします。グローバルな書き込みアクセス権を持つことは、必ずしも悪いことではありません。ただし、その目的は、悪意のあるプログラムや不正なプログラムがファイルを変更または削除するのを防ぐことでもあります.ランサムウェアはその一例であり、Alice によってユーザー権限で実行されます。

    • /home/alice/ --- (drwxrwxrwx アリス アリス)
    • /home/bob/ --- (drwxrwx--- ボブ ボブ)

    上記のシナリオでは、Alice によって実行されたランサムウェアは、アリスが書き込みアクセスを必要とするすべてのファイルを暗号化して上書きします。アリスがしないとすれば グループ bob に所属 と /home/bob/ グローバル rwx がありません アリスにはアクセス権がありません。ただし、Bob がユーザー権限でランサムウェアを実行した場合、Bob は rwx を持っています /home/alice/ のための権限 グローバル rwx を使用 パーミッション。これで、Alice と Bob の両方のホーム ディレクトリがランサムウェアによって暗号化されます。

    ユーザーをグループに追加するのは非常に簡単です。Linux:ユーザーをグループに追加します (プライマリ/セカンダリ/新規/既存)。これにより、ユーザー名が追加されます:alicebob に グループ。 Chown -R bob:bob どこで user:group ディレクトリを再帰的に所有します。 chmod -R 750 rwxr-x--- を再帰的に提供します アクセス許可、Alice が /home/bob/ 内で読み取りおよび実行できるようにする ディレクトリですが、書き込みはできません。

    • sudo adduser alice bob
    • sudo chown -R bob:bob /home/bob/
    • sudo chmod -R 750 /home/bob/

    最小アクセスの原則は、主に悪意のあるユーザーから保護することです。ただし、悪意のあるプログラムも非常に深刻な問題です。これが、グローバルな読み取り、書き込み、および実行が一緒に行われる理由です ------rwx 非常に悪いセキュリティ原則です。このアイデアは alice を追加することで実現されます bob に グループ。今、ユーザー alice r-x あります /home/bob/ へのアクセス許可 bob 外の他のユーザー root 以外のグループはできません。同様に、Bob が Alice とファイルを共有したいが、Alice にはグループ アクセスを許可しない場合は、AB という新しいグループを作成します。 Alice と Bob がグループ内にいる場所を作成できます。ディレクトリ /opt/AB_share/ (rwxrwx---) になりました 作成でき、上記のコマンドが適用されました。 AB 内のもののみ グループはアクセスできます。


    Linux
    1. オープンソースセキュリティに関するリーナスの法則を理解する

    2. Linuxサーバーのセキュリティを開始するための5つのヒント

    3. ファイルとフォルダーのアクセス許可を変更する方法を学ぶ

    1. Linuxでchmod(モード変更)コマンドを使用する方法

    2. Linux コマンドのソース コードを入手する

    3. Chmod 777 をフォルダーとすべてのコンテンツに

    1. chmod() 操作は許可されていません - FatFree フレームワーク

    2. どちらがより広く使用されていますか:chmod 777 または chmod a+rwx

    3. なぜ chmod -R 777 / 破壊的ですか?