サーバーで少し問題が発生しています。一部のユーザーはsudo、たとえばrootになり、rootになることができるはずですが、rootパスワードを変更できないという制限があります。つまり、他のユーザーが何をしても、そのサーバーにログインしてrootになることができるという保証です。

それは可能ですか？

一部のユーザーができること、たとえばsudorootになり、

まあ、それはsudoが解決するように設計された問題なので、その部分は簡単です。

ただし、ユーザーはrootパスワードを変更できないという制限があります。

あなたは、することができますSHWはコメントで指摘した、唯一の特定のアクションは、特定のユーザーで、rootとして取ることができるようにsudoを設定します。つまり、user1の実行sudo services apache2 restartを許可し、user2の実行は許可するが、sudo rebootシステム管理者としての雇用者は許可することができuser3ますsudo -i。そのようなsudoのセットアップ方法に関するハウツーがあります。または、ここで検索（または質問）できます。それは解決可能な問題です。

ただし、シェルへのアクセスsudo -iまたはsudoシェルへのsudo bashアクセスを許可されているユーザー（たとえば、）は何でもできます。これは、sudoがシェルを起動するまでに、sudo自体が見えなくなるためです。別のユーザー（ほとんどの場合はroot）のセキュリティコンテキストを提供しますが、実行されたアプリケーションが何をするのかはわかりません。そのアプリケーションが順番に起動する場合、passwd rootsudoがそれに対してできることは何もありません。これは他のアプリケーションでも実行できることに注意してください。たとえば、より高度なエディタの多くは、シェルを介してコマンドを実行する機能を提供します。シェルは、そのエディタプロセスの有効なuid（つまりルート）で実行されるシェルです。

つまり、他のユーザーが何をしても、そのサーバーにログインしてrootになることができるという保証です。

ごめんなさい; 「rootアクセス権を持つユーザーが何をしても、システムにログインして使用できるようにする」ことを本当に意味する場合、それは（すべての意図と目的のために）実行できません。簡単な "sudo rm / etc / passwd"または "sudo chmod -x / bin / bash"（またはシェルルートが使用するもの）を使用すると、とにかくかなりホースがかかります。「かなりつまらない」とは、「バックアップから復元する必要があり、彼らが指を滑らせることより悪いことをしないことを願っています」という意味です。使用できないシステムにつながる偶発的な事故のリスクを減らすためにいくつかの措置を講じることはできますが、悪意によってシステムをゼロから、または少なくとも既知のものから再構築する必要がある点まで、非常に深刻な問題を引き起こすことを防ぐことはできません良いバックアップ。

システムの自由なルートアクセスをユーザーに与えることにより、そのユーザー（実行することを選択する可能性のあるソフトウェア、lsのような平凡なものも含む）が悪意を持たず、偶然に混乱しないことを信頼します。それがルートアクセスの性質です。

たとえばsudoを介したルートアクセスの制限は少し優れていますが、それでも攻撃ベクトルを開かないように注意する必要があります。また、ルートアクセスには、権限昇格攻撃の攻撃経路が多数あります。

rootが必要とするアクセスレベルでそれらを信頼できない場合は、sudoの設定を非常に厳しくするか、sudoなどの手段を介して問題のユーザーにrootアクセスをまったく許可しないようにする必要があります。

これは事実上不可能です。まず、rootになる権限を付与した場合、何もできないようにするためにできることは何もありません。ユースケースでsudoは、ユーザーにroot権限を付与し、他のユーザーにはroot になることを許可せずに制限するために使用する必要があります。

シナリオでは、suとpasswdコマンドへのアクセスを制限し、他のほとんどすべてへのアクセスを開く必要があります。問題は、ユーザーが直接/etc/shadow（または/etc/sudoersその点で）編集したり、ルートをハイジャックするために置換ルートパスワードをドロップしたりするのを防ぐためにできることは何もないことです。そして、これは可能な限り最も単純な「攻撃」シナリオです。1つまたは2つのコマンドを除き、制限のない権限を持つSudoerは、完全なルートアクセスをハイジャックする制限を回避できます。

示唆されるように唯一の解決策は、コメントでSHW使用することであるsudoユーザーではなく、コマンドの制限されたセットへのアクセスを許可します。

更新

認証にKerberosチケットを使用する場合、これを実現する方法があります。ファイルの使用法を説明するこのドキュメントをお読みください.k5login。

関連する部分を引用します。

ユーザーaliceのホームディレクトリに次の行を含む.k5loginファイルがあるとします。
bob@FOOBAR.ORG
これにより、bobはssh（1）などのKerberosネットワークアプリケーションを使用して、bobのKerberosチケットを使用してaliceのアカウントにアクセスできます。
...
bobは自分のプリンシパルのKerberosチケットを保持しているためbob@FOOBAR.ORG、サイトのホストへのルートアクセスや、aliceのパスワードを変更する機能など、aliceのチケットを必要とする特権はありません。

しかし、私は間違っているかもしれません。私はまだドキュメントを歩いていて、自分でKerberosを試していない。

実際の管理者がめちゃくちゃになったとしても、「緊急管理者」アクセス権があることを確認したいと思っています（それ以外は、メイン管理者を完全に信頼しています）。

人気のあるアプローチ（非常にハック的ですが）は、一般的に名前が付けられた（root逆方向）を持つ2番目のユーザーを持つことuid=0toorです。別のパスワードがあり、バックアップアクセスとして使用できます。追加するには、おそらく編集/etc/passwdして/etc/shadow（root行をコピー）する必要があります。

フェイルセーフ以外はすべてですが、「メイン管理者」が予告なしにパスワードを変更するのを防ぐ必要がある場合は、機能します。toorアカウントを削除して無効にするのは簡単です。そのため、唯一の利点は個別のパスワードを持つことです。

または、sshキーlibnss-extrausers、LDAPなどの代替認証メカニズムを調べることもできます。

管理者がひどく失敗する可能性があることに注意してください。たとえば、ファイアウォールをブロックします。

非常に安全なシステムが必要な場合は、UNIXユーザー（rootなど）にもロールが割り当てられているSELinuxの使用を検討してください。管理者にrootアクセスを許可したい場合がありますが、制限されたロールのみを許可することもできます（たとえば、apacheのみを管理する場合）。ただし、これには、ポリシーを正しく構成するためにかなりの労力が必要になります。

ルートの本質は、システムの無制限のコマンドを持つことです。SELinuxでそれを微調整することもできます（以前は誰でもrootとしてログオンできるデモサイトでしたが、そのパワーはアクセスシステムを介して機能していませんでした）が、それはポイントではありません。ポイントは、これが問題の間違った解決策であるということです。

今、あなたはあなたの問題が何であるかを述べていませんが、これらのユーザーがルートパスワードから手を離すことを信用しないなら、彼らはルートであるビジネスを持っていません。Webサーバー、さまざまなハードウェアデバイス、またはワープドライブなどを管理する必要がある場合は、そのためのソリューションをセットアップします。強力なグループを作成し、必要なすべてのアクセス権を付与して、追加します。ルートのみのシステムコールを実行する必要がある場合は、いくつかのsetuidプログラムを作成します。

もちろん、その種のアクセス（および少しの知識）を持つユーザーはおそらくシステムを簡単にハッキングできますが、少なくともあなたはOSセキュリティモデルで作業しているのであって、それに対してではありません。

PS。パスワードなしでルートアクセスを自分で調整するには、多くの方法があります。/etc/sudoersたとえば、（制限なしで）ログインしている場合、rootになるために必要なのは自分のパスワードだけです（例：）sudo bash。しかし、単にそこに行く必要はないはずです。

少なくとも理論的には、SELinuxを使用してこれを行うことはおそらく可能です。これにより、ユーザーまたはプロセスが何を許可されているか、または許可されていないかについて、より正確なルールを設定できます。SELinuxでも、ユーザーがrootパスワードを変更できないようにするのは難しいかもしれませんが、それでも必要なことは何でもできます。

本当にそれは、rootパスワードを変更することを許可されていないユーザーが実際にできる必要があるかどうかに依存します。たぶんそれを解決し、sudoを使用してこれらのアクセス許可を付与する方がおそらく簡単で安全です。

おそらく、ユーザーに仮想マシンまたはLXCコンテナーへのルートアクセスを許可することを検討する必要があります。これにより、ホストへのログインや管理アクションの実行を妨げることなく、システムへの完全なルートアクセスが許可されます。

それが実際に実行可能であるかどうかはわかりませんが、ここに1つの汚いハックがあります。

1. /etc/passwd実際の呼び出しの前に、ファイルを他の場所にコピーするラッパースクリプト/プログラムを作成します。sudo
2. 通常のユーザーが使用できるようにする sudo
3. 彼がタスクを完了したら、またはsudoから出てきたら、/etc/passwdファイルを復元します

これを達成するために考慮しなければならないプラスマイナスのことがたくさんあります。結局のところ、それは汚いハックです

sudoルートを付与するためだけであり、その後の保護がないステートメントは、明らかに虚偽です。

visudosudoersファイルを変更するために使用します。行の例を次に示します。

redsandro ALL=(ALL:ALL) NOPASSWD:/path/to/command

• redsandroは、許可を与えるユーザー名です。%グループに適用するには、先頭にを置きます。
• ALLは、このルールの名前です。Sudoerは、単にグローバルアクセス許可を付与するだけではありません。それはしかしそれが複雑になるところです。
• = 説明不要
• ALL:ALL（who_to_run_it_as：what_group_to_run_it_as）として読み取ります。これにより、特定のユーザーまたはグループのコンテキストでのみコマンドの実行を許可できます。
• NOPASSWD：パスワードプロンプトをオフにするように指示します。
• /path/to/command 特定のコマンドpath_to_commmand、another_commandを指定できます

覚えておくべきことは、sudo主にホームユーザーがルート権限にエスカレートするために使用されますが、特定のコマンドへのアクセスをよりきめ細かく制御するために使用できることです。

参照資料

• ここでの他の答えから

（私はubuntuを知りませんが、Fedora / Red-Hatに似ているはずです）
ルートパスワードの変更へのアクセスを制限することを想像できる唯一のことは、おそらくsudoまたはSElinuxを使用してアクセスを制限するフルルートアクセスを与えないことですパスワードファイルに...しかし、ルートは一般に無制限のアクセスを持ち、SElinuxを更新するか、パスワードファイルのラベルを変更するか、事前に準備されたプログラムを実行してパスワードを変更するため、多くのアクセスを信頼しません。

パスワードを変更しないほど十分に信頼していない場合は、おそらくルートアクセス権を与えるべきではありません。そうでなければ、あなたは事故を避けようとしていると思います。

ルートへのアクセスのみを保護する場合は、ルートパスワードを復元できるプログラムをセットアップします。これにより、パスワードが変更されても、最小限のアクセスで復元できます。（sudoはそれ自体でうまくいきます）

要件は次のとおりです。

サーバーで少し問題があります[...]、つまり、そのサーバーにログインして、他のユーザーが何をしてもルートになることができるという保証です。

あなたの質問から、あなたはシステムを破壊しようとするランダムな悪意のあるユーザーに直面していないように見えますが、代わりに時々悪戯を引き起こすかもしれない半信頼のユーザーがいます（おそらく学生？）。私の提案は、悪意のあるユーザーによる全面的な攻撃ではなく、その状況に対処するものです。

1. 仮想環境内でサーバーを実行します。サーバーのファイルシステムをマウントし、変更されたファイルを既知の良好なバージョンに置き換えることができます。予想される損傷の可能性に応じて、すべての重要なディレクトリ（/ bin、/ sbin、/ etc、/ usr、/ varなど）のスナップショットを作成し、スナップショットを展開して損傷したファイルを上書きし、残りを残しますシステムはそのまま。

2. システムを読み取り専用で、たとえばDVD-Rから実行します。次回の再起動までシステムのほとんどの部分が静的である場合は、これが適切なオプションです。また、仮想環境で読み取り専用のバッキングストアを使用したり、ネットワーク経由でベースシステムをロードしたりして、新しいDVD-Rを書き込むよりも再起動間の変更をはるかに簡単に行うことができます。

3. カーネルモジュール。カーネルのLinuxセキュリティモジュール（LSM）は、安全なモジュールを作成するための基盤を提供します。LSMはSELinuxで使用されますが、Smack、TOMOYO、AppArmorなど、あまり知られていない単純なシステムでも使用されています。 この記事では、オプションの概要を説明しています。/ etc / passwd、/ etc / shadow、または必要な他のファイルへの書き込みアクセスをrootでも防止するために、すぐに設定できるチャンスの1つです。

4. ＃1と同じ考え方ですが、サーバーが仮想環境にない場合。サーバーをライブCDなどの読み取り専用OSにチェーンロードすると、サーバーのファイルシステムが自動的にマウントされ、起動時にベースシステムが既知の正常なコピーで上書きされます。次に、読み取り専用OSがメインOSで起動します。

5. 繰り返しになりますが、これらが上層部（教師/上司）に対して責任がある半信頼ユーザーであると仮定すると、最良の答えはLinux Auditかもしれません。これにより、セキュリティ関連のすべてのアクションと誰がそれを実行したかがわかります（すべてのユーザーがルートアカウントを共有している場合でも、ユーザーアカウントからsudoが最初に実行されるため、誰がそれを実行したかがわかります）。実際、監査ログをリアルタイムで解析し、破損したファイルを置き換えることもできます。/ etc / shadowは上書きされますか？問題ありません。監視サーバーですぐに既知の正常なバージョンに置き換えてください。

ニーズに基づいて調査する必要のある他のテクノロジー：

• Linux Integrity Measurement Architecture / Extended Verification Module（IMA / EVM）、および
• トラステッドプラットフォームモジュール（TPM）。

他の答えを補完するために、まれな状況でルートの制御を失ったと感じ、そのような場合にはサーバーの再起動が許可されるというシナリオを想定します。（結局、マシンが危険にさらされていると思われる場合は、とにかくオフラインにする必要があります。）

これの大きな利点は、設定するものがないことです。あなたの質問は次のようになります：「ルートパスワードを忘れました。どうすれば元に戻りますか？」そして、その答えは再起動し、マシンが立ち上がったらシングルユーザーモードを選択することです。これにより、パスワードを知らなくてもルートシェルが得られます。その時点で、新しいパスワードを設定できます。（また、行って損傷を修復する...）

サーバーをVM（VirtualBoxなど）にクローンする場合、制限のないルートアクセスを人々に与えることができ、ゲストオペレーティングシステムのパーティションに常に直接アクセスできることを保証できるため、最終的な制御を維持し/etc/passwd、ホストシステムのルートを持っているので、同様。

もちろん、制限のないルートアクセスを与えることは依然として正しい解決策ではない可能性があります。データセキュリティが問題またはあなたの責任である場合、ルートアクセスを放棄することはできません。

この要件は技術的には不可能です。すでに雄弁にコメントされてsudoいるように、ユーザーに無制限またはさらに制限された権限を付与することは、そのユーザーを信頼することを意味します。悪意と十分な技術的能力と忍耐力を持っている人は、設置された障害をすべて通り抜けることができます。

ただし、ユーザーが悪意を持っていないことを信頼できると仮定すると、パスワードの変更に関する制限をポリシーの問題にすることができます。passwd「rootパスワードを変更しないでください」ということを思い出させるプログラムのラッパーを作成できます。これは、問題の原因は、rootパスワードを変更しているユーザーが誤解（パスワードを変更した後で自分のパスワードを変更していると思われる可能性がある）が原因でそれを行っていることであると想定していますsudo bash。

特別な（まれな）状況で、完全な信頼が不可能でありsudo、十分ではあるが合理的に安全なチャンクへのアクセスを遮断できない場合、パスワード変更（またはその他の指定された形式のシステム改ざん）に対する組織的な制裁の確立を検討することができます重要なリソースの監視。設定されたポリシーを回避するために簡単に検出されないようにし、使用規則と監視について公開され、透過的になります。

監視と発見の側面は、その道を歩むことを選択した場合に別の質問から恩恵を受ける難しい技術的な問題です。私には必要なようです

1. ユーザーがIDをルートに変更したことを検出し、作成されたプロセスを追跡します。
2. それ以降のプロセス作成を記録して、各プロセスを担当する元のユーザーが誰であるかを確認し、半信頼ユーザーがログを送信するアクセス権を持たないリモートホストを使用します。
3. 何らかの種類のシステムトレースを使用して、何が起こっているかを記録し、後でポリシー違反の背後に誰がいたかを発見できるようにします。

少なくとも、書き込み、プロセスの作成exec()、およびもちろんネットワークを変更しようとするために、安全なファイルセット以外のログを開く必要があります。

実装は、変更されたlibcまたは（はるかに優れた）システムコールトレースによって実行できます。

もちろん、そのようなトレースとロギングを100％正しく動作させることは不可能であり、実装するのは容易ではなく、動作するために追加のリソースも必要です。これにより、パスワードの変更や他の好ましくないシステムの改ざんが止まることはありませんが、有罪のユーザーを見つけたり、少なくとも監視があるという幻想を作成したり、悪意のあるユーザーの誘いを少なくしたりする可能性が高くなります（ただし、技術的手段の基本的な無益さを理解している問題を愛するハッカーの中には、挑戦を受け入れて、その楽しみのためだけにシステムを回避しようとすることを奨励していると感じるかもしれません）。

元々定式化された質問は役に立たない。主な目標は「まだログインしている」ことのように見えるので、他の人にルートアクセスが許可されていても確実に動作し続けるいくつかの緊急入力について話します。最初に明示的に言及したAnony-Mousseに乾杯。

問題は、所有者がボックスに物理的にアクセスできる場合、システムへの論理アクセスを簡単に回復できることです（ただし、それがまだ生きている場合）。そうでない場合-rootパスワードを保持しても、sshdのダウンや不適切なネットワーク設定などからは救出されません。したがって、とにかくシステムにアクセスできません。

管理者権限を持つユーザーによるシステムの損傷を防ぐ方法についてのトピックは、SEの質問形式に適合するには広すぎるようです。

リモート緊急入力ソリューションについて言えば、最良の方法はIPMI（私が思うに）です。システム所有者はいつでも仮想ドライブを接続し、それから起動して、システムの回復を進めることができます。

IPMIが利用できない場合、上記で既に提案されているように、適切な仮想化技術を回避することができます。

/etc/sudoersファイル内のsudoへのアクセスを制限できます

/ etc / sudoersの構文を完全に説明するために、サンプルルールを使用して各列を分類します。

jorge  ALL=(root) /usr/bin/find, /bin/rm

最初の列は、このsudoルールが適用されるユーザーまたはグループを定義します。この場合、ユーザーjorgeです。この列の単語の前に％記号が付いている場合、システムは同じ名前のユーザーとグループを持つことができるため、この値はユーザーではなくグループとして指定されます。

2番目の値（ALL）は、このsudoルールが適用されるホストを定義します。この列は、sudo環境を複数のシステムに展開するときに最も役立ちます。デスクトップUbuntuシステム、またはsudoロールを複数のシステムにデプロイする予定のないシステムの場合、この値をすべてのホストに一致するワイルドカードであるALLに設定したままにしてください。

3番目の値は括弧内に設定され、最初の列のユーザーがコマンドを実行できるユーザーを定義します。この値はrootに設定されます。これは、最後の列でrootユーザーとして指定されたコマンドを実行できることを意味します。この値はALLワイルドカードに設定することもできます。これにより、jorgeはシステム上の任意のユーザーとしてコマンドを実行できます。

最後の値（/ usr / bin / find、/ bin / rm）は、最初の列のユーザーが3番目の列のユーザーとして実行できるコマンドのコンマ区切りリストです。この場合、jorgeがrootとしてfindとrmを実行できるようにします。この値をALLワイルドカードに設定することもできます。これにより、システム上のすべてのコマンドをrootとして実行することができます。

このことを念頭に、あなたは、カンマ区切り形式でXコマンドを許可することができますし、追加しない限り、passwdこれには、あなたは問題ないはずです

1/2ルートはありません:)ルート権限を与えると、彼らは何でも好きなことができます。または、sudoを使用して、制限されたbashシェルを実行するか、root権限なしでrbash を実行できます。

ルートとしてサーバーにログインするフェイルセーフメカニズムが必要な場合は、別のユーザーをuid=0作成するか、定期的にルートパスワードをリセットする単純なcronを作成できます。

sudoを使用するのではなく、ホイールグループを追加してみてください。sudoを使用すると、ユーザーはrootであるかのように実行できます。つまり、実行と何の違いもありません。

su-

ルートになるために。ルートuid = 0; ホイールuid = 10。人々は名前を使用しますが、OSはuidを使用します。特定のコマンドは、wheelグループのメンバーが実行できません。（wheelを使用する場合、rootをwheelグループのメンバーとして追加するのを間違えないでください）。ホイールがわからない場合は、Red Hatのドキュメントをご覧ください。

別のオプションは、パスワードではなくsshキーを使用することです。sudoを使用しているユーザーが公開キーを〜/ .ssh / authorizedkeysファイルに追加しないことを確認できると仮定すると、ルートパスワードが事実上無視されるため、ルートパスワードの変更に関する懸念を回避できます。

これらのユーザーに信頼を拡張する（独自の公開キーを追加しない）場合は、拡張ファイル属性を使用し、不変ビットを使用してみてください。〜/ .ssh / authorizedkeysファイルを作成し、必要に応じて/ etc / ssh / sshd_configと/ etc / ssh / ssh_configを構成した後、不変ビットを設定します。もちろん、それを台無しにする方法もあります。完璧なものはありません。

どのシステムでも、インサイダーが最も高いリスクです。ショーを実行する人は山の頂上にいます。関連する考えは契約に関係しています。弁護士はあなたに、「あなたが取引をするために契約を必要とする誰かと取引をしないでください」と言うでしょう。常識は、「契約なしにビジネスをしないでください」と教えてくれます。取引を行うのに十分信頼できる人を見つけたら、お互いのニーズに基づいて契約を書きます。

私を含む提出されたすべての回答は、物理的アクセスに対処できません。誰でもそれを制御できます。あなたでない場合は、誰かがあなたがログインできないようにする方法を見つけた場合、またはあなたが後でさえログインする方法を見つけた場合に、あなたがマシンに物理的にアクセスする人を取得する方法があります'それが起こらないようにしようとしました。もちろん、あなたが不便にならないことに興味があるなら、カップルを実装することはとにかく考慮されるべきであるけれども、あなたがこれらのもののどれも必要でないかもしれないより物理的なアクセスを持っているならば。

-ジョン・クラウト

1つの方法/etcは、書き込み不可であることを確認することです。誰も、sudoer周りがある限り。

これは、ネットワーク経由でマウントし、反対側でデバイスを書き込めないようにすることで実現できます。

これは、書き込みアクセスを防ぐローカルデバイスを使用して実行できます。（write blockerハードウェアを調べる）

重要な部分は、そのマシンのルート概念の外側で制限を適用する必要があるということです。創造的なハッカーは、彼が制御できる環境内であなたがemに置くすべての障害を回避します。そのため、rootがパスワードを変更できる場合、そうすることもできますsudoer。

ユーザーがログイン機能を台無しにできないことを確認するには、読み取り専用でマウントする必要が/binあり/sbinます。

また、ネットワーク接続を定期的に復元するスクリプトが必要です。

（補足：sudoerに非常に限られたコマンドセットのみを許可し、それらのコマンドごとにコマンドのブレーク/置換などができないように保護している場合、/etc書き込み可能な間はそれを防ぐことができます。）