답변:
커널 모듈 서명 기능은 설치 중에 모듈을 암호화하여 서명 한 다음 모듈을로드 할 때 서명을 확인합니다. 따라서 서명되지 않은 모듈 또는 유효하지 않은 키로 서명 된 모듈을로드 할 수 없어 커널 보안이 향상됩니다. 모듈 서명은 악성 모듈을 커널에로드하기 어렵게하여 보안을 강화합니다. 모듈 서명 확인은 커널에 의해 수행되므로 신뢰할 수있는 사용자 공간 비트가 필요하지 않습니다.
이 기능은 X.509 ITU-T 표준 인증서를 사용하여 관련된 공개 키를 인코딩합니다. 서명 자체는 산업 표준 유형으로 인코딩되지 않습니다. 이 기능은 현재 RSA 공개 키 암호화 표준 만 지원합니다 (플러그 가능하고 다른 사용자가 사용할 수 있음). 사용할 수있는 해시 알고리즘은 SHA-1, SHA-224, SHA-256, SHA-384 및 SHA-512입니다 (알고리즘은 서명의 데이터로 선택됨).
모듈 서명 기능은 커널 구성의 "로드 가능한 모듈 지원 활성화"섹션으로 이동하여 활성화합니다.
CONFIG_MODULE_SIG "Module signature verification"
여기에는 여러 가지 옵션이 있습니다.
"모듈이 올바르게 서명되어야합니다"(CONFIG_MODULE_SIG_FORCE)
이것은 키가 알려지지 않은 서명이 있거나 서명되지 않은 모듈을 커널이 처리하는 방법을 지정합니다.
이 기능이 꺼져 있으면 (예 : "허용") 키를 사용할 수없고 서명되지 않은 모듈은 허용되지만 커널은 오염 된 것으로 표시되고 관련 모듈은 오염 된 것으로 표시됩니다. 문자 'E'로.
이것이 켜져 있으면 (즉, "제한적") 커널 소유의 공개 키로 확인할 수있는 유효한 서명을 가진 모듈 만로드됩니다. 다른 모든 모듈은 오류를 생성합니다.
여기에서 설정에 관계없이, 모듈에 구문 분석 할 수없는 서명 블록이있는 경우 수동으로 거부됩니다.
"모든 모듈에 자동 서명"(CONFIG_MODULE_SIG_ALL)
이것이 켜져 있으면 모듈은 빌드의 modules_install 단계에서 자동으로 서명됩니다. 이 옵션이 꺼져 있으면 다음을 사용하여 모듈에 수동으로 서명해야합니다.
scripts/sign-file
"어떤 해시 알고리즘으로 모듈에 서명해야합니까?"
설치 단계에서 모듈에 서명 할 해시 알고리즘을 선택할 수 있습니다.
CONFIG_MODULE_SIG_SHA1 "Sign modules with SHA-1"
CONFIG_MODULE_SIG_SHA224 "Sign modules with SHA-224"
CONFIG_MODULE_SIG_SHA256 "Sign modules with SHA-256"
CONFIG_MODULE_SIG_SHA384 "Sign modules with SHA-384"
CONFIG_MODULE_SIG_SHA512 "Sign modules with SHA-512"
여기서 선택한 알고리즘은 모듈이 아닌 커널에 내장되어 해당 알고리즘으로 서명 된 모듈이 종속성 루프를 발생시키지 않고 서명을 확인할 수 있습니다.
"모듈 서명 키의 파일 이름 또는 PKCS # 11 URI"(CONFIG_MODULE_SIG_KEY)
이 옵션을 기본값 "certs / signing_key.pem"이외의 다른 것으로 설정하면 서명 키의 자동 생성이 비활성화되고 선택한 키로 커널 모듈에 서명 할 수 있습니다. 제공된 문자열은 개인 키와 PEM 형식의 해당 X.509 인증서 또는 OpenSSL ENGINE_pkcs11이 작동하는 시스템에서 RFC7512에 의해 정의 된 PKCS # 11 URI를 포함하는 파일을 식별해야합니다. 후자의 경우 PKCS # 11 URI는 인증서와 개인 키를 모두 참조해야합니다.
개인 키를 포함하는 PEM 파일이 암호화되거나 PKCS # 11 토큰이 PIN을 요구하는 경우 KBUILD_SIGN_PIN 변수를 사용하여 빌드시 제공 할 수 있습니다.
"기본 시스템 키링에 대한 추가 X.509 키"(CONFIG_SYSTEM_TRUSTED_KEYS)
이 옵션은 기본적으로 시스템 키링에 포함되는 추가 인증서를 포함하는 PEM 인코딩 파일의 파일 이름으로 설정할 수 있습니다.
모듈 서명을 활성화하면 OpenSSL 개발 패키지에 대한 종속성이 서명을 수행하는 도구의 커널 빌드 프로세스에 추가됩니다.
서명을 생성하고 확인하려면 암호화 키 쌍이 필요합니다. 개인 키는 서명을 생성하는 데 사용되고 해당 공개 키는 서명을 확인하는 데 사용됩니다. 개인 키는 빌드 중에 만 필요하며 그 후에 안전하게 삭제하거나 저장할 수 있습니다. 공개 키는 커널에 내장되어 모듈이로드 될 때 서명을 확인하는 데 사용될 수 있습니다.
정상적인 조건에서 CONFIG_MODULE_SIG_KEY가 기본값에서 변경되지 않은 경우, 커널 빌드는 파일에 존재하지 않는 경우 openssl을 사용하여 새 키 쌍을 자동으로 생성합니다.
certs/signing_key.pem
다음의 매개 변수를 사용하여 vmlinux를 빌드하는 동안 (키의 공개 부분은 vmlinux에 빌드해야합니다)
certs/x509.genkey
파일 (없는 경우에도 생성됨).
고유 한 x509.genkey 파일을 제공하는 것이 좋습니다.
특히 x509.genkey 파일에서 req_distinguished_name 섹션은 기본값에서 변경되어야합니다.
[ req_distinguished_name ]
#O = Unspecified company
CN = Build time autogenerated kernel key
#emailAddress = unspecified.user@unspecified.company
생성 된 RSA 키 크기는 다음을 사용하여 설정할 수도 있습니다.
[ req ]
default_bits = 4096
Linux 커널 소스 트리의 루트 노드와 openssl 명령에서 x509.genkey 키 생성 구성 파일을 사용하여 키 개인 / 공용 파일을 수동으로 생성 할 수도 있습니다. 다음은 공개 / 개인 키 파일을 생성하는 예입니다.
openssl req -new -nodes -utf8 -sha256 -days 36500 -batch -x509 \
-config x509.genkey -outform PEM -out kernel_key.pem \
-keyout kernel_key.pem
결과로 생성 된 kernel_key.pem 파일의 전체 경로 이름은 CONFIG_MODULE_SIG_KEY 옵션에 지정 될 수 있으며 인증서와 키가 자동 생성 된 키 쌍 대신 사용됩니다.
커널은 루트로 볼 수있는 공개 키 링을 포함합니다. ".system_keyring"이라는 키링에 있으며 다음과 같이 볼 수 있습니다.
[root@deneb ~]# cat /proc/keys
...
223c7853 I------ 1 perm 1f030000 0 0 keyring .system_keyring: 1
302d2d52 I------ 1 perm 1f010000 0 0 asymmetri Fedora kernel signing key: d69a84e6bce3d216b979e9505b3e3ef9a7118079: X509.RSA a7118079 []
...
모듈 서명을 위해 특별히 생성 된 공개 키 외에 CONFIG_SYSTEM_TRUSTED_KEYS 구성 옵션이 참조하는 PEM 인코딩 파일에 추가로 신뢰할 수있는 인증서를 제공 할 수 있습니다.
또한, 아키텍처 코드는 하드웨어 저장소로부터 공개 키를 가져 와서 (예를 들어, UEFI 키 데이터베이스로부터) 공개 키를 추가 할 수있다.
마지막으로 다음을 수행하여 추가 공개 키를 추가 할 수 있습니다.
keyctl padd asymmetric "" [.system_keyring-ID] <[key-file]
예 :
keyctl padd asymmetric "" 0x223c7853 <my_public_key.x509
그러나 새 키의 X.509 래퍼에 키를 추가 할 때 이미 .system_keyring에있는 키로 서명 된 경우 커널은 키를 .system_keyring에 추가 할 수만 있습니다 .
모듈에 수동으로 서명하려면 Linux 커널 소스 트리에서 사용 가능한 스크립트 / sign-file 도구를 사용하십시오. 이 스크립트에는 4 가지 인수가 필요합니다.
1. The hash algorithm (e.g., sha256)
2. The private key filename or PKCS#11 URI
3. The public key filename
4. The kernel module to be signed
다음은 커널 모듈에 서명하는 예입니다.
scripts/sign-file sha512 kernel-signkey.priv \
kernel-signkey.x509 module.ko
사용 된 해시 알고리즘은 구성된 알고리즘과 일치 할 필요는 없지만, 그렇지 않은 경우 해시 알고리즘이 커널에 내장되어 있는지 또는 자체 요구없이로드 될 수 있는지 확인해야합니다.
개인 키에 암호 또는 PIN이 필요한 경우 $ KBUILD_SIGN_PIN 환경 변수에 제공 할 수 있습니다.
서명 된 모듈에는 마지막에 단순히 디지털 서명이 추가됩니다. 문자열 "~ 모듈 서명 추가 ~." 모듈 파일의 끝에서 서명이 있음을 확인하지만 서명이 유효한지 확인하지 않습니다!
서명이 정의 된 ELF 컨테이너 외부에 있으므로 서명 된 모듈은 BRITTLE입니다. 따라서 서명이 계산되고 첨부되면 제거 될 수 없습니다. 전체 모듈은 서명시 존재하는 모든 디버그 정보를 포함하여 서명 된 페이로드입니다.
사용자 공간에서 처리가 수행되지 않으므로 서명되지 않은 모듈과 마찬가지로 insmod, modprobe, init_module () 또는 finit_module ()이 모듈에로드됩니다. 서명 확인은 모두 커널 내에서 수행됩니다.
커널 명령 행에 CONFIG_MODULE_SIG_FORCE가 활성화되어 있거나 enforcemodulesig = 1이 제공되면, 커널은 공개 키가있는 유효한 서명 된 모듈 만로드합니다. 그렇지 않으면 서명되지 않은 모듈도로드됩니다. 커널에 키가 있지만 서명이 일치하지 않는 모듈은로드 할 수 없습니다.
구문 분석 할 수없는 서명이있는 모든 모듈은 거부됩니다.
개인 키는 모듈에 서명하는 데 사용되므로 바이러스 및 맬웨어는 개인 키를 사용하여 모듈에 서명하고 운영 체제를 손상시킬 수 있습니다. 개인 키는 파괴되거나 안전한 위치로 이동해야하며 커널 소스 트리의 루트 노드에 유지되지 않아야합니다.