一部のシステムで Magic SysRq がデフォルトで有効になっていないのはなぜですか?危険がありますか?

一部のシステムで Magic SysRq がデフォルトで有効になっていないのはなぜですか?危険がありますか?

Oracle Linux 6.3サーバー(RHEL派生)の問題を解決する際に、まずMagic SysRq Keyコマンドをいくつか試してみました。そんな運がなくてハードリブートをしなければなりませんでした。戻ったときにSysRqが有効になっていることを確認しました。

> sysctl kernel.sysrq
kernel.sysrq = 0

しかし、Oracle Linux 7.2(RHEL派生)システムでは...

> sysctl kernel.sysrq
kernel.sysrq = 16

見ているsysrqのカーネル文書:

0 - disable sysrq completely
1 - enable all functions of sysrq
>1 - bitmask of allowed sysrq functions (see below for detailed function
description):
     2 =   0x2 - enable control of console logging level
     4 =   0x4 - enable control of keyboard (SAK, unraw)
     8 =   0x8 - enable debugging dumps of processes etc.
    16 =  0x10 - enable sync command
    32 =  0x20 - enable remount read-only
    64 =  0x40 - enable signalling of processes (term, kill, oom-kill)
   128 =  0x80 - allow reboot/poweroff
   256 = 0x100 - allow nicing of all RT tasks

~によるとFedoraのSysrq品質保証:

デフォルトのFedoraおよびRHELカーネルはこの機能を有効にしてコンパイルされますが、ディストリビューションは起動時にsysctl.confを使用してデフォルトでこの機能を無効にします。

すべてのシステムでこの機能をデフォルトで有効にするのが良い考えです。まれにシステムがロックされている場合は、少なくとも半分で正常にシャットダウンできます。

私の質問...

  1. これが本当に良いアイデアである場合、なぜこの機能は6.Xで無効になり、7.Xではファイルシステムの同期に制限されますか?
  2. すべてのシステムにkernel.sysrqこれを設定すると危険がありますか?1

ベストアンサー1

おそらく、ランダムな人がキーボードに近づいてシステムをリセットしたり、悪い場合は、ログインせずにレジスタ、syslog、またはすべてのタスクをコンソールに印刷し始めたくありません。これは潜在的なセキュリティ問題です。

たとえば、シリアルコンソールコンセントレータに接続されているデータセンターハードウェアでオプションで有効にします。エンドユーザーワークステーションはこれを無効にします。

おすすめ記事