지난 1~2년 동안 Linux 커널 모듈을 블랙리스트에 추가하려고 여러 번 시도했지만(blacklist.conf 또는 커널 명령줄 매개변수를 통해) 작동하지 않았습니다. 어쨌든 모듈은 커널에 로드되었습니다. 여기에는 블랙리스트 모듈을 시도할 때 발생하는 유사한 어려움과 관련하여 다음과 같은 몇 가지 질문이 제기된 것 같습니다.
modprobe.d 및 커널 매개변수의 블랙리스트 모듈이 작동하지 않습니다.
/etc/modprobe.d/blacklist.conf를 통해 커널 모듈을 제외하면 작동하지 않습니다.
그렇다면 Linux의 블랙리스트 동작이 왜 그렇게 취약할까요?
Sourcejedi가 그의 기사에서 언급했듯이답변, 모듈 블랙리스트는 커널에서 구현되지 않지만 modprobe실제로 사용자 공간 도구는 옵션을 사용해야 합니다 -b. modprobe그렇지 않으면 블랙리스트에 있는 모듈을 로드하게 됩니다.
그러나 이것은 약한 행동에 대한 나의 요점으로 돌아옵니다. 즉, 사용자 공간 도구는옵트블랙리스트를 존중하세요. 사용자 공간 도구는 모듈 블랙리스트를 무시해야 합니까, 아니면 시스템 관리자에게 이 동작이 필요한 이유는 무엇입니까? 사용자 공간 도구로 간단히 무시할 수 없도록 블랙리스트를 커널에 구현하는 것이 더 합리적이지 않을까요? 확실히 이것이 더 강력한 정책이겠죠?
아니면 modprobe블랙리스트 정책을 기본적으로 단순히 따라서는 안 되는 이유는 무엇입니까? 왜 무시할 수 있는 옵션인가요?
간단히 말해서 이는 설계가 좋지 않기 때문입니까, 아니면 블랙리스트 동작을 더 간단하고 강력하게 만들 수 없는 이유가 있습니까?
답변1
현재 구현
블랙리스트는 커널에 의해 구현되지 않습니다. 에 의해 구현됩니다 modprobe.
사용자가 명명된 모듈을 로드하도록 수동으로 요청하면 블랙리스트의 영향을 받지 않습니다.
블랙리스트는 1) udev가 하드웨어를 감지하면 자동으로 로드하고 2) request_module() 호출이 다음을 위한 경우 request_module()에 대한 커널 호출을 통해 요청 시 모듈이 로드되는 것을 방지하기 위해 존재합니다.모듈 별칭또는 .char-major-10-237net-pf-10-proto-132
(udev 사용은 별칭을 사용하여 모듈을 로드하는 경우에도 적용됩니다. 예를 들어 별칭은 드라이버 모듈이 scsi:t-0x01*필요한 scsi 장치에 사용됩니다 st.)
modprobemodprobe에 전달되지 않은 모듈 이름으로 호출된 스크립트는 -b블랙리스트의 영향을 받지 않습니다. 이에 따라 스크립트를 수정하도록 요청할 수 있습니다.추측하다이것이 해당 옵션을 갖는 이유입니다 -b. 또는 다른 방법을 사용하여 문제의 스크립트를 비활성화합니다 :-).
별칭이 아닌 이름으로 모듈을 요청하는 커널의 request_module() 사용이 있을 수도 있습니다. 을(를) 실행할 때 request_module() -b이 통과하지 못했습니다 modprobe.
modprobe블랙리스트는 다른 모듈의 요구 사항으로 커널 모듈을 로드할 때도 참조되지 않습니다. 특정 드라이버 모듈의 자동 로드를 중지하고 싶을 때 이는 큰 문제가 되지 않습니다. udev가 로드하는 모듈을 알아내거나 몇 가지 다른 가능성을 블랙리스트에 추가해야 할 수도 있습니다.
따라서 원래 커널 설계에 대해 질문했지만 명령이 modprobe기본적으로 이를 암시하지 않는 이유를 물어볼 수도 있습니다.-b
설계
[블랙리스트]를 무시하는 옵션이 있는 이유는 무엇입니까?
분명히 "모듈이 자동으로 로드되는 것을 원하지 않지만 필요할 때 수동으로 로드할 수 있기를 원하는 경우"입니다.
내 기본 가정은 이것이 설계 목표가 아니며 우연히 달성하지 못한다는 것입니다. 설계가 널리 채택되면 특정 유형의 변경은 위험하거나 기존 시스템을 손상시킬 수 있습니다. 나는 또한 블랙리스트가 모듈 로딩 명령의 첫 번째 버전의 일부가 아니라는 점을 지적하고 싶습니다.
또한 이와 같은 구성 라인은 install bad-module /bin/false위에서 언급한 모든 "약점"을 방지합니다. 기술적으로 이는 "지정되지 않았습니다. [설치 명령]을 대체하기 위한 것입니다." 지금까지 "오랜 기간 동안 사용"되었으며 적어도 한 번 이상의 재작성/재라이센스( module-init-tools프로젝트-> kmod프로젝트)를 거쳤습니다. 하나는 대안을 구현했습니다.
사용자의 예를 찾았습니다.하다~ 고 싶어요블랙리스트 우회. 그러나 이것은 아주 좋은 예는 아닌 것 같습니다. 이 스레드는 분명히 옳은 일인 것처럼 보이는 다른 솔루션을 보여주기 때문입니다.
실험할 때 현재 블랙리스트에 있는 모듈을 사용할지 확인하는 것도 편리합니다. 떠오르는 가장 확실한 예는 전체 재부팅을 테스트하려는 그래픽 드라이버이므로 블랙리스트 파일을 편집하는 것이 가장 좋습니다.
약점
위 답변의 약점 -
request_module() 호출이 발생할 때 표시되는 로깅이 없는 것 같습니다. 따라서 가능한 요인으로 request_module() 호출을 배제하려는 경우 여기에는 투명성이 별로 없습니다.
모듈이 로드되면
lsmod다른 모듈에서 사용 중인지 쉽게 확인할 수 있습니다. 그러나 예를 들어 모듈에 오류가 너무 많아 로드 시 시스템이 즉시 충돌하는 경우에는 도움이 되지 않습니다. :-). 그리고 특정 모듈 X에 대해 어떤 모듈이 엄격한 요구 사항을 가지고 있는지 검색하기 위해 미리 만들어진 명령이 없는 것 같습니다.modprobe --show-depends X반대 방향이 표시됩니다.기타 알려지지 않은 복잡성. 위의 사항 중 어느 것이 질문의 문제를 설명하는지 여부가 실제로 명확하지 않기 때문입니다.modprobe.d 및 커널 매개변수의 블랙리스트 모듈이 작동하지 않습니다.