☰

일부 시스템에서 Magic SysRq가 기본적으로 활성화되지 않는 이유는 무엇입니까? 위험이 있나요?

tag-icon • tag-icon fedora rhel kernel oracle-linux 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 또는 모든 작업을 콘솔에 인쇄하기 시작하는 것을 원하지 않을 것입니다. 이는 잠재적인 보안 문제입니다.

예를 들어 직렬 콘솔 집중 장치에 연결된 데이터 센터 하드웨어에서 선택적으로 활성화합니다. 최종 사용자 워크스테이션에서는 이를 비활성화합니다.

관련 정보