rootパスワードを変更できないrootアクセス？
サーバーで少し問題があります。一部のユーザーが実行できるようにする必要があります。 Sudoそしてrootになりますが、ユーザーはrootパスワードを変更できないという制限があります。つまり、他のユーザーが何をするかに関係なく、そのサーバーにログインしてrootになることができるという保証です。
それは可能ですか？
一部のユーザーが実行できるようにする必要があります。
Sudoそしてrootになり、
まあ、それは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 rootを起動した場合、Sudoがそれについてできることは何もありません。これは他のアプリケーションでも実行できることに注意してください。たとえば、より高度なエディターの多くは、シェルを介してコマンドを実行する機能を提供します。シェルは、そのエディタープロセスの有効なuidで実行されます（つまり、ルート）。
つまり、他のユーザーが何をするかに関係なく、そのサーバーにログインしてrootになることができるという保証です。
ごめんなさい; 「rootアクセス権を持つユーザーがシステムにログインしても、システムにログインして使用できることを確認する」ということを本当に意味している場合、それは（すべての意図と目的のために）実行することはできません。簡単な「Sudo rm/etc/passwd」または「Sudo chmod -x/bin/bash」（またはシェルのルートが使用するものなら何でも）で、とにかく大いに夢中になっています。 「かなり大げさな」とは、「バックアップから復元する必要があり、指が滑るだけで何も起こらないことを望んでいる」という意味です。 偶発的な事故が発生してシステムが使用できなくなるリスクを軽減するためにいくつかの手順を実行できますが、悪意による非常に深刻な問題の発生を防ぐことはできませんシステムを最初から、または少なくとも既知の適切なバックアップから再構築する必要があるポイントを含みます。
システム上の自由なrootアクセスをユーザーに与えることにより、そのユーザー（実行することを選択する可能性のあるすべてのソフトウェアを含み、lsのようなありふれたものも含む）が悪意を持たず、誤って混乱しないようにします。これがrootアクセスの性質です。
制限付きrootアクセス（例： Sudoは少し優れていますが、攻撃ベクトルを開かないように注意する必要があります。また、ルートアクセスでは、特権昇格攻撃の可能性のある攻撃ベクトルがたくさんあります。
ルートであることを伴うアクセスのレベルでそれらを信頼できない場合は、verySudo構成を厳しくするか、単に問題のユーザーに、Sudoまたはその他の方法でrootアクセスを許可しないでください。
これは事実上不可能です。まず第一に、もしあなたが彼らにbecoming rootの力を与えるなら、彼らが何もしないようにするためにあなたができることは何もありません。ユースケースでは、Sudoを使用して、ユーザーにいくつかのroot権限を付与し、他のユーザーを制限する必要がありますユーザーがrootになることを許可せずに。
シナリオでは、suおよびpasswdコマンドへのアクセスを制限し、他のほとんどすべてへのアクセスを開く必要があります。問題は、ユーザーが編集できないようにする方法はありません/etc/shadow（または/etc/sudoersそのことについて）直接、Hijack rootに代替のrootパスワードをドロップします。そして、これは可能な限り最も単純な「攻撃」シナリオです。 1つまたは2つのコマンドを除いて無制限のパワーを持つSudoerは、完全なルートアクセスをハイジャックする制限を回避できます。
コメントのSHW で提案されている唯一の解決策は、Sudoを使用して、制限された一連のコマンドへのアクセスをユーザーに許可することです。
更新
認証にKerberosチケットを使用する場合、これを実現する方法があるかもしれません。読む このドキュメント.k5loginファイル。
私は関連する部分を引用します：
ユーザーaliceのホームディレクトリに、次の行を含む.k5loginファイルがあるとします。
[email protected]
これにより、ボブはssh（1）などのKerberosネットワークアプリケーションを使用して、ボブのKerberosチケットを使用してアリスのアカウントにアクセスできます。
...
ボブは自分のプリンシパルのKerberosチケットを保持しているため、[email protected]、彼には、サイトのホストへのrootアクセスや、アリスのパスワードを変更する機能など、アリスのチケットを必要とする特権はありません。
しかし、私は間違っているかもしれません。私はまだドキュメントを調べていて、まだ自分のためにKerberosを試していません。
実際の管理者が失敗した場合でも、「緊急管理者」アクセス権があることを確認したいと思います（ただし、それ以外の場合は、メイン管理者を完全に信頼します）。
一般的なアプローチ（非常にハックですが）は2番目のユーザーにuid=0を使用することであり、一般的にtoor（ルート後方）と呼ばれます。パスワードが異なり、バックアップアクセスとして使用できます。追加するには、おそらく/etc/passwdおよび/etc/shadowを編集する必要があります（root行をコピーします）。
それはすべてフェイルセーフですが、「メインの管理者」が予告なくパスワードを変更しないように保護する必要がある場合は、機能します。 toorアカウントを削除して無効にするのは簡単です。したがって、唯一の利点は、個別のパスワードを持つことです。
または、代替の認証メカニズム、つまりsshキー、libnss-extrausers、LDAPなどを確認することもできます。
管理者はまだひどく台無しにすることができることに注意してください。たとえば、ファイアウォールをブロックします。
非常に安全なシステムが必要な場合は、SELinuxを使用することを検討してください。UNIXユーザー（例：root）もロールを持っているため、さらに細かくすることができます。管理者にルートアクセスを付与することもできますが、役割は制限する必要があります（Apacheのみを管理するなど）。ただし、ポリシーを正しく構成するには、かなりの労力が必要になります。
少なくとも理論的には、 SELinux を使用してこれを実行することはおそらく可能です。これにより、ユーザーまたはプロセスが何を行うことが許可されているか、または許可されていないかについて、より正確なルールを設定できます。 SELinuxを使用する場合でも、ユーザーがrootパスワードを変更できないようにするのは難しいかもしれませんが、それでもユーザーが必要とするあらゆることを実行できます。
実際には、rootパスワードの変更を許可されていないユーザーが実際に何を実行できる必要があるかによって異なります。それが何であるかを考え出し、特にSudoを使用してそれらのアクセス許可を付与する方がおそらく簡単で安全でしょう。
Rootの本質は、システムの無制限のコマンドを持つことです。 SELinuxでそれを調整することもできます（以前は誰でもrootとしてログオンできるデモサイトでしたが、そのパワーはアクセスシステムを介して機能していませんでした）が、それは重要ではありません。ポイントはこれはあなたの問題に対する間違った解決策です。
さて、あなたはあなたの問題が何であるかを述べていませんが、これらのユーザーがrootパスワードから手を離すのを信頼していない場合、彼らはrootになることはできません。彼らが管理する必要がある場合ウェブサーバー、またはさまざまなハードウェアデバイス、またはワープドライブなどのソリューションをセットアップします。強力なグループを作成し、必要なすべてのアクセス権を付与して、グループに追加します。 root専用のシステムコールを実行する必要がある場合は、いくつかのsetuidプログラムを記述します。
もちろん、そのようなアクセス権（および多少の知識）を持つユーザーは、おそらくシステムをハッキングする可能性がありますが、少なくとも、OSのセキュリティモデルではなく、セキュリティモデルで作業しています。
PS。パスワードなしでrootアクセスを自分で手配する方法はたくさんあります。たとえば、/etc/sudoersにいる場合（制限なし）、rootになるには自分のパスワードのみが必要です。 Sudo bash。しかし、そこに行く必要はありません。
おそらく、ユーザーに仮想マシンまたはLXCコンテナーへのrootアクセスを許可することを検討する必要があります。これにより、ホストへのログインや管理アクションの実行を妨げることなく、システムへの完全なルートアクセスが可能になります。
Sudoはrootを許可するためだけのものであり、それ以降は何の保護もないことは露骨に誤りです。
visudoを使用して、sudoersファイルを変更します。これが行の例です：
redsandro ALL=(ALL:ALL) NOPASSWD:/path/to/command
redsandroは、許可するユーザー名です。%は、グループに適用するために前面にあります。ALLは、このルールの名前です。 Sudoersは、単にグローバルなアクセス許可を付与するだけではありません。それが複雑になるところです。=説明は不要ALL:ALLは（who_to_run_it_as：what_group_to_run_it_as）として読み取ります。この方法では、特定のユーザーまたはグループのコンテキストでのみ、コマンドの実行を許可できます。NOPASSWD：パスワードプロンプトをオフにするように指示します。/path/to/command特定のコマンドpath_to_commmand、another_commandを指定できます
覚えておくべきことは、Sudoは主にホームユーザーがroot権限にエスカレートするために使用しますが、特定のコマンドへのアクセスをより細かく制御するために使用でき、使用することです。
参考文献
- 私の他の答えから ここ
それが実際に実行可能かどうかはわかりませんが、ここに1つの汚いハックがあります。
- 実際の
Sudoを呼び出す前に、/etc/passwdファイルを他の場所にコピーするラッパースクリプト/プログラムを記述します - 通常のユーザーに
Sudoの使用を許可する - タスクが完了したら、またはSudoを終了したら、
/etc/passwdファイルを復元します
私は知っています、これを達成するために考慮しなければならないプラスマイナスの事柄がたくさんあります。結局のところ、それはdirty hackです。
あなたの要件は：
サーバーで少し問題があります。[...]つまり、他のユーザーが何をするかに関係なく、そのサーバーにログインしてrootになることができるという保証です。
あなたの質問から、システムを破壊しようとするランダムな悪意のあるユーザーに直面していないようですが、代わりに、時々悪戯を引き起こす可能性のある半信頼されたユーザーがいます（学生？）私の提案は、悪意のあるユーザーによる全面的な攻撃ではなく、その状況に対処しています。
仮想環境内でサーバーを実行します。サーバーのファイルシステムをマウントし、変更されたファイルを正常なバージョンに置き換えることができます。予想される損傷に応じて、すべての重要なディレクトリ（/ bin、/ sbin、/ etc、/ usr、/ varなど）のスナップショットを作成し、そのスナップショットを展開して、損傷したファイルを上書きし、残りのファイルは残します。システムは無傷。
システムを読み取り専用で実行します。 DVD-Rから。次の再起動まで、システムのほとんどの部分を静的に保つことができる場合、これは良いオプションです。また、仮想環境で読み取り専用のバッキングストアを使用したり、ネットワーク経由で基本システムを読み込んだりして、新しいDVD-Rを書き込むよりもリブート間の変更をはるかに簡単に行うことができます。
カーネルモジュール。カーネルのLinux Security Modules（LSM）は、安全なモジュールを作成するための基礎を提供します。 LSMはSELinuxで使用されますが、Smack、TOMOYO、AppArmorなどのあまり知られていない単純なシステムでも使用されます。 この記事 は、オプションの概要を示しています。可能性としては、/ etc/passwd、/ etc/shadow、またはその他の必要なファイルへの書き込みアクセスをrootであっても防ぐために、すぐに構成できる可能性があります。
＃1と同じアイデアですが、サーバーが仮想環境にない場合。ライブCDなどの読み取り専用OSにサーバーチェーンをロードすると、サーバーのファイルシステムが自動的にマウントされ、各起動時にベースシステムが正常なコピーで上書きされます。次に、読み取り専用OSがメインOSで起動します。
繰り返しになりますが、これらが上級者（教師/上司）に責任を負う準信頼ユーザーであるとすると、最善の答えは Linux Audit です。これにより、セキュリティ関連のすべてのアクションとその実行者がわかります（すべてのユーザーがrootアカウントを共有している場合でも、最初にユーザーアカウントからSudoが実行されるため、誰が実行したかがわかります）。実際、監査ログをリアルタイムで解析して、破損したファイルを置き換えることもできます。/etc/shadowが上書きされましたか？問題ありません。監視サーバーにすぐに、それを既知の適切なバージョンに置き換えてもらいます。
ニーズに基づいて調査したいその他のテクノロジー：
- Linuxインテグリティ測定アーキテクチャ/拡張検証モジュール （IMA/EVM）、および
- 信頼できるプラットフォームモジュール （TPM）。
（ubuntuはわかりませんが、Fedora/Red-Hatと同様のはずです）
ルートパスワードの変更へのアクセスを制限すると想像できるのは、Sudoを使用したり、SElinuxを使用してパスワードファイルへのアクセスを制限したりすることだけですが、あまり信頼できません。 rootとしてのアクセスには通常、無制限のアクセス権があり、SElinuxを更新したり、パスワードファイルのラベルを付け直したり、事前に準備されたプログラムを実行してパスワードを変更したりできます。
パスワードを変更できないほど十分に信頼していない場合は、ルートアクセスを許可しないでください。そうでなければ私はあなたが事故を回避しようとしていると思います。
Rootへのアクセスを保護するだけの場合は、rootパスワードを復元できるプログラムをセットアップしてください。これにより、パスワードが変更された場合でも、最小限のアクセスで復元できます。 （sudoはそれ自体でうまく機能します）
要件は技術的に不可能です。すでに雄弁にコメントしているように、無制限またはさらに制限されたSudo権限をユーザーに付与することは、あなたがtrustそのユーザーであることを意味します。邪悪な意図と十分な技術的能力と忍耐力を持つ人は、置かれているあらゆる障害を乗り越えることができます。
ただし、ユーザーが悪意のないものであると信頼できる場合は、パスワードの変更を制限することができますpolicy。 passwdプログラム用のラッパーを作成して、「ルートパスワードを変更しないでください」と通知することができます。これは、問題の原因がルートパスワードを変更しているユーザーが誤解（たとえば、_Sudo bash_を実行した後で自分のパスワードを変更していると考えているため）が原因であることを前提としています。
特別な（まれな）状況下で、if complete信頼が不可能で、Sudo適切ではあるが合理的に安全なチャンクへのアクセス。パスワードの変更（またはその他の指定された形式のシステム改ざん）に対して組織の制裁措置を確立することを検討し、重要なリソースの監視を調整してeasy設定されたポリシーを回避するために検出されないようにし、使用規則と監視について公開し、透過的になります。
監視と発見の側面は、その道を歩むことを選択した場合、別の質問から恩恵を受ける困難な技術的問題です。私には私たちがする必要があるようです
- ユーザーがIDをrootに変更したことを検出し、作成されたプロセスを追跡します。
- それ以降、プロセスの作成をログに記録して、各プロセスを担当する元のユーザーを確認し、半信頼されたユーザーがログを送信するためのアクセス権を持たないリモートホストを使用します。
- ある種のシステムトレースを使用して、何が起こっているのかをログに記録し、laterを使用して、ポリシー違反の背後にいる人物を見つけます.
少なくとも、書き込み、プロセスの作成、exec()、およびもちろんネットワークを変更する試みのために、安全なファイルセット以外のファイルのオープンをログに記録する必要があります。
実装は、変更されたlibcまたは（はるかに優れた）システムコールトレースによって行うことができます。
もちろん、そのようなトレースとロギングを100％正しく機能させることは不可能であり、実装は容易ではありません。また、操作するには追加のリソースも必要です。これはstopパスワードの変更や他の歓迎されないシステムの改ざんを行いませんが、有罪ユーザーを見つけるか、少なくとも作成することを可能にします監視があり、それをlessにするという幻想（一部の悪意のあるユーザーを招待します（ただし、技術的対策の基本的な無益性を見るハッカーを愛するいくつかの問題）その場で挑戦を受け入れ、その楽しみのためだけにシステムを回避しようとすることが奨励されるかもしれません。
他の答えを補足するために、ルートの制御を失うことはまれな状況であると認識し、そのような場合はサーバーの再起動が許可されるというシナリオを想定します。 （結局のところ、マシンが危険にさらされていると思われる場合は、とにかくそれをオフラインにする必要があります。）
これの大きな利点は、構成するものがないことです。あなたの質問は次のようになります：「rootパスワードを忘れてしまいました。どうすれば元に戻すことができますか？ "そして、その答えは、再起動し、マシンが起動したらシングルユーザーモードを選択することです。これにより、パスワードを知らなくてもルートシェルを利用できます。その時点で、新しいパスワードを設定できます。 （同様に、損傷があれば修理してください...）
サーバーをVM（ VirtualBox など）に複製する場合、自由なrootアクセスを人々に与えることができ、常に直接アクセスできることを保証できますゲストオペレーティングシステムのパーティション。したがって、/etc/passwdなど。ホストシステムにrootが存在するため。
もちろん、自由なrootアクセスを与えることは、まだ適切な解決策ではない可能性があります。データのセキュリティがまったく問題であるか、あなたの責任である場合、rootアクセスを与えることはできません。
独自に作成された質問は無意味です。主な目的は「まだログインしている」ことなので、他の人にrootアクセスが許可されている場合でも確実に機能し続ける緊急入力について話します。最初にそれを明示的に指摘したAnony-Mousseに乾杯。
問題は次のとおりです。所有者がボックスに物理的にアクセスできる場合、論理アクセスをシステムに簡単に回復できます（ただし、それがまだ稼働している場合）。そうでない場合-rootパスワードを保持しても、たとえばsshdがダウンしているか、ネットワークが正しく設定されていないため、システムにアクセスできません。
管理者権限を持つ人によるシステムの損傷を防ぐ方法についてのトピックは、SEの質問形式に適合するには広すぎるようです。
リモート緊急入力ソリューションといえば、最善の方法はIPMI（私が思う）が利用できる場合です。システム所有者は、いつでも仮想ドライブを接続し、そこから起動して、システムの回復を処理できます。
IPMIが利用できない場合、すでに上で提案されているように、適切な仮想化技術が回避策になる可能性があります。
/etc/sudoersファイルでSudoへのアクセスを制限できます
/ etc/sudoersの構文を完全に説明するために、サンプルルールを使用して各列を分類します。
jorge ALL=(root) /usr/bin/find, /bin/rm
最初の列は、このSudoルールが適用されるユーザーまたはグループを定義します。この場合は、ユーザーjorgeです。この列のWordの前に％記号が付いている場合、システムは同じ名前のユーザーとグループを持つことができるため、この値はユーザーではなくグループとして指定されます。
2番目の値（ALL）は、このSudoルールが適用されるホストを定義します。この列は、複数のシステムにSudo環境をデプロイするときに最も役立ちます。デスクトップUbuntuシステム、またはSudoの役割を複数のシステムにデプロイする予定がないシステムの場合、この値をすべてのホストに一致するワイルドカードであるALLに設定してもかまいません。
3番目の値は括弧内に設定され、最初の列のユーザーがコマンドを実行できるユーザーを定義します。この値はrootに設定されます。これは、jorgeが最後の列で指定されたコマンドをrootユーザーとして実行できることを意味します。この値はALLワイルドカードに設定することもできます。これにより、jorgeはシステム上の任意のユーザーとしてコマンドを実行できます。
最後の値（/ usr/bin/find、/ bin/rm）は、最初の列のユーザーが3番目の列のユーザーとして実行できるコマンドのコンマ区切りリストです。この場合、jorgeがfindとrmをrootとして実行できるようにします。この値はALLワイルドカードに設定することもできます。これにより、jorgeはシステム上でrootとしてすべてのコマンドを実行できます。
これを念頭に置いて、コンマ区切り形式でXコマンドを許可できます。これにpasswdを追加しない限り、問題ありません。