複数のユーザーがリモートでログインするヘッドレスサーバーがあります。他のユーザーはsudoersファイルに含まれていないため、Sudo
経由でrootを取得できません。ただし、su
の権限は-rwsr-xr-x
rootパスワードをブルートフォースで攻撃しようとするのを妨げるものは何もありません。
ユーザーがrootパスワードを知っていれば、システムを危険にさらす可能性があると主張する人もいますが、私はそうではないと思います。 OpenSSHはPermitRootLogin no
およびPasswordAuthentication no
、他のユーザーはサーバーに物理的にアクセスできません。私の知る限り、世界は/usr/bin/su
は、ユーザーが私のサーバーでrootを獲得しようとする唯一の方法です。
それが役に立たないように見えるという点で私をさらに困惑させていることsu
を直接実行しなくても、Sudo su
、しかしこれはほとんど不便ではありません。
私は何かを見落としているか?歴史的な理由から、世界はsu
に対する実行権限を持っていますか?私がまだ遭遇していないその許可を削除することの欠点はありますか?
ilkkachuの答え に欠けている点の1つは、ルートへの昇格はsu
の特定の用途の1つにすぎないということです。 suの一般的な目的は、別のユーザーのログインアカウントで新しいシェルを開くことです。その他のユーザーcouldはroot
(おそらくほとんどの場合はそうです)ですが、su
を使用して、ローカルシステムが認証できるany IDを想定できます。
たとえば、ユーザーjim
としてログインしていて、mike
から報告された問題を調査したいが、再現できない場合は、mike
としてログインし、問題を引き起こすコマンドを実行してみます。 。
13:27:20 /home/jim> su -l mike
Password:(I type mike's password (or have him type it) and press Enter)
13:27:22 /home/mike> id
uid=1004(mike) gid=1004(mike) groups=1004(mike)
13:27:25 /home/mike> exit # this leaves mike's login Shell and returns to jim's
13:27:29 /home/jim> id
uid=1001(jim) gid=1001(jim) groups=1001(jim),0(wheel),5(operator),14(ftp),920(vboxusers)
su
の-l
オプションを使用すると、完全なログインが(man
ページごとに)シミュレートされます。
ただし、上記にはmike
のパスワードの知識が必要です。 Sudo
へのアクセス権があれば、パスワードがなくてもmike
としてログインできます。
13:27:37 /home/jim> Sudo su -l mike
Password:(I type my own password, because this is Sudo asking)
13:27:41 /home/mike>
要約すると、su
実行可能ファイルのアクセス許可が表示されているのは、su
が汎用ツールであり、システム。
歴史的には(GNU以外のユニックスでは)そうではなかったか、少なくともsu
に許可された "wheel"というグループに属しているかどうかを手動でチェックしていました。 GNU su
のバージョン)は、当時のRMSのアクセス制御に関するイデオロギーのため、この機能を再現しませんでした。
Why GNU `su' does not support the `wheel' group
===============================================
(This section is by Richard Stallman.)
Sometimes a few of the users try to hold total power over all the
rest. For example, in 1984, a few users at the MIT AI lab decided to
seize power by changing the operator password on the Twenex system and
keeping it secret from everyone else. (I was able to thwart this coup
and give power back to the users by patching the kernel, but I wouldn't
know how to do that in Unix.)
However, occasionally the rulers do tell someone. Under the usual
`su' mechanism, once someone learns the root password who sympathizes
with the ordinary users, he or she can tell the rest. The "wheel
group" feature would make this impossible, and thus cement the power of
the rulers.
I'm on the side of the masses, not that of the rulers. If you are
used to supporting the bosses and sysadmins in whatever they do, you
might find this idea strange at first.
この問題については、「ホイールグループのrms」などでグーグル検索することで、さらに多くのことを見つけることができます。
ただし、
su
の権限は-rwsr-xr-x
rootパスワードをブルートフォースで攻撃しようとするのを妨げるものは何もありません。
はい。通常のLinuxシステムを想定すると、pam_unix.so
モジュールは、失敗した認証試行を〜2秒遅らせますが、同時試行を停止するものはないと思います。
失敗した試行はもちろん記録されます:
Aug 16 22:52:33 somehost su[17387]: FAILED su for root by ilkkachu
パスワードを監視するためのシステムがある場合、パスワードをブルートフォースで強制すると、ログに目立つように表示されるはずです。信頼できないローカルユーザーがいる場合は、そうする必要があります。信頼できないローカルユーザーは、ローカルのみの権限昇格の悪用を試みる可能性もあり、リモート権限昇格よりもはるかに一般的です。
それが役に立たないように見えるという点で、私をさらに困惑させていること。
もちろん、これは便利です。パスワードがわかっている場合は、root
に昇格できます。
su
を直接実行しなくても、Sudo su
、しかしこれはほとんど不便ではありません。
Sudo su
は多少冗長です。別のユーザーとしてプログラムを実行できるようにするための2つのプログラムを使用する必要はありません。1つで十分です。 Sudo -i
またはSudo -s
(またはSudo /bin/bash
など)シェルを実行する場合。
私は何かを見落としているか?歴史的な理由から、世界はsuに対して許可を与えるだけですか?
上記を参照。ええと、すべてのシステムが代替としてSudo
を持っているわけではありません。これを歴史的であると考えるかどうかはわかりません。
私がまだ遭遇していないその許可を削除することの欠点はありますか?
実際には、私が知る限りではありません。 I think特定のグループ( "su
")のメンバーだけが実行できるように、一部のシステムではwheel
が設定されています。必要に応じて、Sudo
にも同じことができます(chown root.sudousers /usr/bin/Sudo && chmod 4710 /usr/bin/Sudo
)。
または、必要がなければ、プログラムのいずれかまたは両方を削除することもできます。 Debianでは、su
にはlogin
パッケージが付属しているため、パッケージ全体を削除することはおそらくお勧めできません。 (そしてlogin
とsu
を一緒にペアリングすることは、やや歴史的なように見えます。)
あなたはすでにいくつかの良い答えを持っていますが、彼らが対処していないあなたの投稿の一部があります。
私の知る限り、/ usr/bin/suに対する実行権限は、ユーザーが私のサーバーでrootを獲得しようとする唯一の方法です。
それは危険な仮定です。 rootに適切なパスワードを設定した場合、ほとんどの場合、特権エスカレーションが成功するのは、カーネルまたはsetuidバイナリのバグの悪用によるものです(もちろん、setuidを削除することもできます)それらから少しですが、passwd
はsetuidであり、高度なセキュリティが必要な場合は、それをユーザーにも提供する必要があります。ユーザーを拒否すると、パスワードを変更するオプションは互換性がありません)。
suは誰でも実行できるように、世界中で実行可能である必要があります。多くのシステムでは、パスワードを入力することにより、別のユーザーに変更するために使用できます。
誰かがrootパスワードをブルートフォースで実行することに懸念がある場合は、それを無効にすることができます。 (ハッシュを無効にして、特定のパスワードが一致しないようにします)
コンセンサスについてはわかりませんが、rootとして直接ログインできること自体がセキュリティ上の問題であると考えています。