web-dev-qa-db-ja.com

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

Oracle Linux 6.3サーバー（RHEL Derivative）のトラブルシューティング中に、Magic SysRq Keyコマンドのいくつかを初めて使用しようとしました。そのような運がなかったので、私はハードリブートしなければなりませんでした。それが戻ってきたとき、私はSysRqが有効になっているかどうかを確認しました...

> sysctl kernel.sysrq
kernel.sysrq = 0

しかし、Oracle Linux 7.2（RHEL Derivative）システムでは...

> 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 に対するQAによると：

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

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

私の質問...

  1. それが明らかに良いアイデアである場合、なぜ6.Xでは機能が無効になり、7.Xではfilsystem同期のみに制限されるのですか？
  2. 設定にリスクはありますかkernel.sysrqから1すべてのシステムで？
fedorarhelkerneloracle-linuxmagic-sysrq
8
Caesar Kabalan

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

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

3
jsbillings