10.2. PAM 구성 파일 정보
각 PAM 인식 애플리케이션 또는 서비스에는
/etc/pam.d/ 디렉터리에 파일이 있습니다. 이 디렉터리의 각 파일의 이름은 액세스를 제어하는 서비스와 동일합니다. 예를 들어 로그인 프로그램은 서비스 이름을 login 로 정의하고 /etc/pam.d/login PAM 구성 파일을 설치합니다.
주의
PAM 구성 파일을 수동으로 편집하는 대신 authconfig 도구를 사용하여 PAM을 구성하는 것이 좋습니다.
10.2.1. PAM 구성 파일 형식
각 PAM 구성 파일에는 모듈(인증 구성 영역)을 정의하는 지시문 그룹과 모든 제어 또는 인수를 포함합니다.
지시문에는 모듈 목적(인터페이스)과 모듈의 구성 설정을 식별하는 간단한 구문이 있습니다.
module_interface control_flag module_name module_arguments
PAM 구성 파일에서 모듈 인터페이스는 정의된 첫 번째 필드입니다. 예를 들어 다음과 같습니다.
auth required pam_unix.so
PAM 인터페이스는 특정 모듈이 수행할 수 있는 인증 작업의 유형입니다. 각각 인증 및 권한 부여 프로세스의 다른 측면에 해당하는 4가지 유형의 PAM 모듈 인터페이스를 사용할 수 있습니다.
- auth - 이 모듈 인터페이스는 사용자를 인증합니다. 예를 들어 암호의 유효성을 요청하고 확인합니다. 이 인터페이스의 모듈은 그룹 멤버십과 같은 자격 증명을 설정할 수도 있습니다.
- account - 이 모듈 인터페이스는 액세스가 허용되는지 확인합니다. 예를 들어 사용자 계정이 만료되었는지 또는 사용자가 특정 시간에 로그인할 수 있는지 확인합니다.
- password - 이 모듈 인터페이스는 사용자 암호를 변경하는 데 사용됩니다.
- 세션 - 이 모듈 인터페이스는 사용자 세션을 구성하고 관리합니다. 이 인터페이스의 모듈은 사용자의 홈 디렉터리를 마운트하고 사용자의 사서함을 사용할 수 있도록 액세스를 허용하는 데 필요한 추가 작업도 수행할 수 있습니다.
개별 모듈은 일부 또는 모든 모듈 인터페이스를 제공할 수 있습니다. 예를 들어
pam_unix.so 는 4개의 모듈 인터페이스를 모두 제공합니다.
pam_unix.so 와 같은 모듈 이름은 PAM에 지정된 모듈 인터페이스가 포함된 라이브러리 이름을 제공합니다. 애플리케이션이 올바른 버전의 모듈을 찾을 수 있는
libpam 의 적절한 버전에 연결되어 있기 때문에 디렉터리 이름이 생략됩니다.
모든 PAM 모듈은 호출 시 성공 또는 실패 결과를 생성합니다. Control 플래그는 PAM에 결과와 함께 수행할 작업을 지시합니다. 모듈은 특정 순서로 나열(스택)될 수 있으며, 제어 플래그는 특정 모듈의 성공 또는 실패가 사용자를 서비스에 인증하는 전체 목표에 얼마나 중요한지를 결정합니다.
몇 가지 간단한 플래그가 있습니다.[2], 키워드만 사용하여 구성을 설정합니다.
- required - 인증을 계속하려면 모듈 결과가 성공해야 합니다. 이 시점에서 테스트가 실패하면 해당 인터페이스를 참조하는 모든 모듈의 결과가 완료될 때까지 사용자에게 알리지 않습니다.
- 필수 조건 - 모듈 결과가 인증을 계속하려면 성공해야 합니다. 그러나 이 시점에서 테스트에 실패하면 첫 번째 실패 또는 필수 모듈 테스트를 반영하는 메시지와 함께 사용자에게 즉시 알림을 받습니다.
- sufficient - 모듈 결과가 실패하는 경우 무시됩니다. 그러나 모듈 결과에 sufficient 으로 플래그가 지정되어 있고 필요한 이전 모듈이 실패한 경우 다른 결과가 필요하지 않으며 사용자가 서비스에 인증됩니다.
- 선택 사항 - 모듈 결과가 무시됩니다. 다른 모듈이 인터페이스를 참조하지 않는 경우 성공적인 인증에만 선택 옵션으로 플래그가 지정됩니다.
- include - 다른 제어와 달리 모듈 결과가 처리되는 방법과 관련이 없습니다. 이 플래그는 지정된 매개 변수와 일치하는 구성 파일의 모든 행을 가져와 모듈에 인수로 추가합니다.
모듈 인터페이스 지시문을 스택 하거나 서로 배치하여 여러 모듈을 한 용도로 함께 사용할 수 있습니다.
참고
모듈의 제어 플래그에서
sufficient 또는 requisite 값을 사용하는 경우 모듈이 나열되는 순서가 인증 프로세스에 중요합니다.
관리자는 스태킹을 사용하여 사용자가 인증하기 전에 특정 조건을 사용해야 할 수 있습니다. 예를 들어 설정 유틸리티는 일반적으로 PAM 구성 파일에 표시된 대로 여러 개의 스택된 모듈을 사용합니다.
[root@MyServer ~]# cat /etc/pam.d/setup auth sufficient pam_rootok.so auth include system-auth account required pam_permit.so session required pam_permit.so
auth sufficient pam_rootok.so- 이 행은pam_rootok.so모듈을 사용하여 UID가 0인지 확인하여 현재 사용자가 root인지 확인합니다. 이 테스트에 성공하면 다른 모듈이 확인되지 않고 명령이 실행됩니다. 이 테스트가 실패하면 다음 모듈이 참조됩니다.auth include system-auth- 이 행에는/etc/pam.d/system-auth모듈의 콘텐츠가 포함되어 인증을 위해 이 콘텐츠를 처리합니다.계정 필수 pam_permit.so- 이 줄은pam_permit.so모듈을 사용하여 root 사용자 또는 콘솔에 로그인한 모든 사용자가 시스템을 재부팅할 수 있도록 허용합니다.세션 필수 pam_permit.so- 이 행은 세션 설정과 관련이 있습니다.pam_permit.so를 사용하면설정유틸리티가 실패하지 않습니다.
PAM은 인수를 사용하여 일부 모듈에 대한 인증 중에 플러그형 모듈에 정보를 전달합니다.
예를 들어
pam_pwquality.so 모듈은 암호가 얼마나 강하고 여러 개의 인수를 사용할 수 있는지 확인합니다. 다음 예에서 enforce_for_root 는 루트 사용자의 암호도 강력한 검사를 성공적으로 통과해야 하며 재시도는 사용자가 강력한 암호를 입력할 수 있는 세 가지 기회를 수신하도록 정의합니다.
password requisite pam_pwquality.so enforce_for_root retry=3
잘못된 인수는 일반적으로 무시되며 그렇지 않으면 PAM 모듈의 성공 또는 실패에 영향을 주지 않습니다. 그러나 일부 모듈은 유효하지 않은 인수에서 실패할 수 있습니다. 대부분의 모듈은
journald 서비스에 오류를 보고합니다. journald 및 관련 journalctl 툴을 사용하는 방법에 대한 자세한 내용은 시스템 관리자 가이드를 참조하십시오.
참고
journald 서비스는 Red Hat Enterprise Linux 7.1에서 도입되었습니다. 이전 버전의 Red Hat Enterprise Linux에서 대부분의 모듈은 오류를 /var/log/secure 파일에 보고합니다.
10.2.2. 주석이 있는 PAM 구성 예
예 10.1. “간단한 PAM 구성” 샘플 PAM 애플리케이션 구성 파일입니다.
예 10.1. 간단한 PAM 구성
#%PAM-1.0 auth required pam_securetty.so auth required pam_unix.so nullok auth required pam_nologin.so account required pam_unix.so password required pam_pwquality.so retry=3 password required pam_unix.so shadow nullok use_authtok session required pam_unix.so
- 첫 번째 줄은 행 시작 부분에 해시 표시(#)로 표시된 주석입니다.
- 로그인 인증을 위해 2-4개의 스택 3개 모듈을 행합니다.auth required pam_securetty.so - 이 모듈은 사용자가 root로 로그인하려고 하는 경우 해당 파일이 있는 경우 사용자가 로그인하는 TTY가
/etc/securetty파일에 나열되도록 합니다.TTY가 파일에 나열되지 않은 경우 root로 로그인하려고 하면로그인 잘못된메시지와 함께 실패합니다.auth required pam_unix.so nullok - 이 모듈은 사용자에게 암호를 묻는 다음/etc/passwd에 저장된 정보를 사용하여 암호를 확인하고, 존재하는 경우/etc/shadow.nullok 인수는pam_unix.so모듈을 지시하여 빈 암호를 허용합니다. - auth required pam_nologin.so - 최종 인증 단계입니다.
/etc/nologin파일이 있는지 확인합니다. 존재하고 사용자가 root가 아닌 경우 인증에 실패합니다.참고이 예제에서는 첫 번째 auth 모듈이 실패하더라도 세 개의 auth 모듈이 모두 확인됩니다. 이렇게 하면 사용자가 인증에 실패한 단계에서 알 수 없습니다. 공격자는 이러한 지식을 통해 시스템을 크래핑하는 방법을 보다 쉽게 줄일 수 있습니다. - 계정 필수 pam_unix.so - 이 모듈은 필요한 계정 확인을 수행합니다. 예를 들어 shadow 암호가 활성화된 경우
pam_unix.so모듈의 계정 인터페이스에서 계정이 만료되었는지 또는 사용자가 허용된 유예 기간 내에 암호를 변경하지 않았는지 확인합니다. - 암호 required pam_pwquality.so retry=3 - 암호가 만료된 경우
pam_pwquality.so모듈의 password 구성 요소에서 새 암호를 입력하라는 메시지를 표시합니다. 그런 다음 새로 생성된 암호를 테스트하여 사전 기반 암호 크래킹 프로그램으로 쉽게 결정할 수 있는지 확인합니다.retry=3 인수는 테스트가 처음으로 실패하면 사용자에게 강력한 암호를 만들 가능성이 두 개 더 있음을 나타냅니다. - 암호 required pam_unix.so shadow nullok use_authtok - 이 줄은 프로그램이
pam_unix.so모듈의 암호 인터페이스를 사용하여 사용자의 암호를 변경하는 경우 를 나타냅니다.- 인수 shadow 는 사용자의 암호를 업데이트할 때 섀도우 암호를 생성하도록 모듈에 지시합니다.
- nullok 인수는 사용자가 빈 암호 에서 암호를 변경할 수 있도록 모듈에 지시합니다. 그렇지 않으면 null 암호가 계정 잠금으로 처리됩니다.
- 이 행의 마지막 인수인 use_authtok 에서는 PAM 모듈을 스택할 때 순서가 중요합니다. 이 인수는 모듈에 새 암호를 요청하는 메시지를 표시하지 않도록 지시합니다. 대신 이전 암호 모듈에서 기록한 암호를 허용합니다. 이렇게 하면 모든 새 암호가 허용되기 전에 보안 암호를 위해
pam_pwquality.so테스트를 전달해야 합니다.
- 세션 required pam_unix.so - 최종 줄은
pam_unix.so모듈의 세션 인터페이스에 세션을 관리하도록 지시합니다. 이 모듈은 사용자 이름과 서비스 유형을 각 세션의 시작과 종료 시/var/log/secure에 기록합니다. 이 모듈은 추가 기능을 위해 다른 세션 모듈과 스택하여 보완할 수 있습니다.
