PAM (Pluggable Authentication Modules)

- PAM 의 필요성

로그인시 암호를 두 번 입력하게 할 수 있나요?

FTP 서버처럼 ( ftpusers 파일) telnet 서버에 접속할 수 있는 사용자를 방화벽이나 tcp_wrapper를 통하지 않고 파일로 관리할 수 있나요?

-> PAM 을 이용하면 다 가능하다. 

-  PAM ( 착탈형 인증 모듈 ) 이란?

시스템 관리자가 응용프로그램들이 사용자를 인증하는 방법을 선택할 수 있도록 해 주는 공유 라이브러리 묶음이다. 즉, 사용자를 인증하고 그 사용자의 서비스에 대한 액세스를 제어하는 모듈화된 방법을 말한다. PAM은 관리자가 응용프로그램들의 사용자 인증 방법을 선택할 수 있도록 해 준다. 필요한 공유 라이브러리의 묶음을 제공하여 PAM을 사용하는 응용프로그램을 재컴파일없이 인증 방법을 변경할 수 있다.

- 다양한 응용 프로그램과 함께 사용할 수 있는 공통 인증체계를 제공한다.

- 시스템 관리자와 응용 프로그램 개발자 모두에게 상당한 유연성과 인증 제어 기능을 제공한다.

- 개발자가 자신의 인증 스키마를 만들지 않고도 프로그램을 작성할 수 있게 해주는 완벽하게 문서화 된 단일 라이브러리를 제공한다.

	PAM aware APP.	PAM library	PAM File	PAM Module
	/bin/su	/lib/libpam.so.0	/etc/pam.d/su	/lib/security/*

- PAM  구성 파일의 문법

type / control / module-path / module-arguments

1. type ( 모듈 종류 , 모듈 인터페이스 )

타입 토큰은 PAM에 이 모듈에 어떤 타입의 인증이 사용될 것 인지를 알려준다. 같은 타입의 모듈은 "쌓일" 수 있고, 사용자에 인증되기 위한 다중 요구사항을 만족하도록 요청할 수 있다. PAM은 네 개의 타입을 인식한다.

	종류	설명
	auth	- 이 모듈 인터페이스는 사용을 인증한다. 예를 들어 암호의 유효성을 요청하고 검증한다. 이 모듈을 사용하여 그룹 구성원 자격 또는 Kerberos 티켓과 같은 자격 증명을 설정할 수도 있다.  - 주로 패스워드를 통하지만 생체 인증과 같은 보다 정교한 방법을 통해서 사용자가 자신이 주장하는 사용자가 맞는지 결정한다.   - 인증이 아닌 계정 관리를 수행한다. 이것은 보통 시간/날짜 현재의 시스템 자원 상황(최대 사용자 수)이나 사용자의 위치(root는 콘솔에서만 로그인이 가능하다)등에 따라 서비스에 대한 접근을 허가하거나 제한하는 것이다.
	account	- 이 모듈 인터페이스는 액세스가 허용되는지 확인한다. 예를 들어 사용자 계정이 만료되었는지 또는 특정 시간대에 사용자가 로그인할 수 있는지 여부를 확인한다.  - 계정(account)은 사용자가 해당 서비스에 접근이 허용되었는지, 패스워드가 기간이 만료가 되었는 지를 결정한다.   - 사용자 인증의 두 가지 면을 제공한다. 첫 번째는, 응용프로그램이 사용자에게 패스워드를 물어보거나 다른 확인 방법을 사용하도록 해서 그 사용자가 자신이 주장하는 사람이 맞는지 확인하는 것이다. 두 번째는, 그룹 멥버쉽을 주거나 credential(신임)속성을 통해 다른 권한을 주는 것이다.
	password	- 이 모듈 인터페이스는 사용자 암호를 변경하는데 사용한다.  - 패스워드는 사용자가 그들의 인증을 변경하도록 어떤 방법을 제공한다. 이것은 주로 패스워드이다. 사용자와 연관된 인증 토큰(패스워드)들을 갱신할 때 필요하다.  - 보통 challenge/response 방식에 기반한 인증모듈 종류별로 각각 하나의 password 모듈씩 존재한다.
	session	- 이 모듈 인터페이스는 사용자 세션을 구성하고 관리한다. 이 인터페이스가 있는 모듈은 사용자의 홈디렉토리를 마운트하고 사용자의 사서함을 사용할 수 있게 하는 등 액세스를 허용하는데 필요한 추가 작업을 수행할 수도 있다.  - 이것은 사용자 홈 디렉토리를 마운팅/언마운팅하는 것과 로그인/로그아웃 그리고 사용자에게 제공하는 서비스를 제한/제공하는 것과 같은 것을 포함할 수 있다.

2. control ( 제어 플래그 )

모든 PAM 모듈은 호출 될 때 성공 또는 실패 결과를 생성한다. 제어 플래그는 PAM에 결과와 어떤 관계가 있는지 알려준다. 모듈은 특정 순서로 스택 될 수 있으며, 제어 플래그는 특정 모듈의 성공 또는 실패가 사용자를 서비스에 인증하는 전체 목표에 얼마나 중요한지 결정한다. 

PAM은 네 가지의 통제 형식을 인식한다.

	종류	설명
	requisite	(필수: 모듈 결과가 성공하면 다음 라인으로 넘어가고, 모듈 결과가 실패하면 첫번째 실패 required 또는 requistie 모듈 테스트를 반영한 메세지를 반환한다.) 인증을 계속하려면 모듈 결과가 성공해야 한다. 그러나, 이 시점에서 테스트가 실패하면 사용자는 첫번째 실패 required 또는 requisite 모듈 테스트를 반영하는 메세지를 즉시 통보한다. 다시 말해서, 이 모듈을 이용하는 인증이 실패할 경우, 즉시 인증을 거부하도록 한다. 사용자가 안전하지 않은 매체(media)에서 패스워드를 입력할 경우에 대비해 사용할 수 있다. 이러한 행동은 크래커에게 시스템의 유효한 계정을 알려줄 수 있다. 이 가능성은 민감한 패스워드를 적대적인 환경에 노출시키는 것에 대한 사소하지 않은 염려와 비교해서 검토해야 한다.
	required	(필요: 모듈 결과가 성공하면 다음 라인으로 넘어가고, 모듈 결과가 실패해도 다음 라인으로 넘어가서 성공하지 않은 경우의 최종결과는 실패이다.) 인증을 계속하려면 모듈 결과가 성공해야 한다. 이 시점에서 테스트가 실패하면 해당 인터페이스를 참조하는 모든 모듈 테스트의 결과가 완료 될때까지 사용자에게 알리지 않는다. required 모듈이 호출되는 순서는 중요하지 않다. 플래그 sufficient 및 requisite 제어 플래그만이 명령을 중요하게 만든다.
	sufficient	(충분: 모듈 결과가 성공하였고 이전 required가 실패하지 않은 경우 서비스에 대해 인증되고, 모듈 결과가 실패하면 다음라인으로 넘어간다.) 모듈 결과가 실패하면 무시된다. 그러나 플래그 sufficient가 지정된 모듈의 결과가 성공적이며, 플래그 된 이전 모듈 required가 실패하지 않은 경우 다른 결과는 필요하지 않으며, 사용자는 서비스에 대해 인증된다.
	optional	(옵션: 다른 모듈의 성공/실패가 없는 경우 optional 모듈의 결과로 결정된다. 하지만, 다른 모듈의 성공/실패가 있다면, optional 모듈의 결과는 무시된다.) 이 모듈이 성공 또는 실패하는지는 그 모듈이 서비스에 대한 형식에 대한 유일한 모듈일 경우에 중요하다. 보통 PAM은 모듈의 성공/실패 판단시에 이런 모듈을 무시한다. 그러나 이전/이후의 모듈들이 명확한 성공/실패가 없다면 이 모듈이 응용그램에게 주는 결과로 결정짓는다.
	include	(포함: PAM 파일을 지정할 때 사용한다.) 다른 컨트롤과 달리 모듈 결과가 처리되는 방식과 관련이 없다. 이 플래그는 지정된 매개 변수와 일치하는 구성 파일의 모든 행을 가져와서 모듈에 인수로 추가한다.

- module-path ( 모듈 경로 )

모듈경로는 PAM에게 어떤 모듈을 사용할 것인지(선택적으로) 그리고 그것을 어디서 찾을 지를 알려준다. 대부분 구성은 로그인 구성파일의 경우와 마찬가지로 모듈의 이름만 가지고 있다. 이와 같은 경우, PAM은 기본 PAM 모듈의 디렉토리에서(보통 /usr/lib/security) 모듈을 찾는다. 그러나 여러분의 리눅스가 리눅스 파일시스템의 표준을 따른다면 PAM 모듈은 /lib/security에 있다.

# cd /lib/security ; ls

- module-argument ( 모듈 인수 )

모듈-인수는 모듈에게 전달되는 인수이다. 각각의 모듈은 각각의 인수를 가지고 있다.

잘못된 모듈인수는 무시되며, PAM 모듈의 성공 또는 실패에는 영향을 주지 않는다. 그러나 일부 모듈은 잘못된 인수로 인해 실패할 수 있다. 대부분의 모듈은 /var/log/secure 파일에 오류를 보고한다.

# man pam_wheel

- 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_cracklib.so retry=3 password required pam_unix.so shadow nullok use_authtok session required pam_unix.so

auth  required  pam_securetty.so 

root 사용자가 로그인을 시도하는 경우 /etc/securetty 파일을 보고, root 사용자에게 허용될 수 있는 터미널을 확인한다. 파일에 tty가 나열되어 있지 않으면, 로그인을 시도는 'Login incorrect' 메세지와 함께 실패한다. 만약 일반 사용자라면 이 모듈은 무시된다.

auth  required  pam_unix.so nullok 

사용자에게 암호를 묻는 메세지를 표시한 다음 /etc/passwd, /etc/shadow 파일에 저장된 정보를 확인한다. nullok는 암호에 공백을 허용하도록 하는 인자값이다.

auth  required  pam_nologin.so

/etc/nologin 파일이 있는지 여부를 확인하고, 파일이 없으면 인증에 성공하고, 파일이 있으면서 root 사용자가 아니라면 인증에 실패한다. root 사용자는 /etc/nologin 파일이 있어도 로그인 가능하다.

첫번째 auth 모듈이 실패하도라도 세개의 모듈 전부를 확인한다.(pam_securetty.so, pam_unix.so, pam_nologin.so)

-> securetty 파일에 pts/1 ~ 11 이 없어서 root로 접속이 불가능하다고 해도 암호를 입력할 수 있다. 

account  required  pam_unix.so

필요한 계정 확인을 수행한다. 예를 들어 쉐도우 암호가 활성화 된 경우, 계정이 만료되었거나 사용자가 허용된 유예기간내에 암호를 변경하지 않았는지 확인한다.

password  required  pam_cracklib.so retry=3

암호가 만료된 경우 pam_cracklib.so 모듈의 암호 구성요소는 새 암호를 묻는 메시지를 표시한다. 그런 다음 새로 생성된 암호를 테스트하여 사전 기반 암호 해독 프로그램에서 쉽게 확인할 수 있는지 여부를 확인한다. retry=3는 테스트가 처음 실패한 경우 사용자가 강력한 암호를 작성할 기회가 2번 더 있음을 나타낸다.

password  required  pam_unix.so shadow nullok use_authok

사용자가 암호를 변경하는 경우의 지정이다. shadow는 사용자 암호를 업데이트 할 때 쉐도우 암호를 만들도록 모듈에 지시하는 인자이다. nullok는 모듈이 빈 암호로 변경할 수 있도록 지시하는 인자이다. nullok 인자가 없다면, 빈 암호(Null password)는 계정 잠금으로 처리된다. use_authok는 사용자에게 새 암호를 입력하라는 메시지를 표시 하도록 지시하는 인자이다. 이전 암호 모듈에 의해 기록된 암호를 승인한다. 이런 식으로 모든 새 암호는 pam_cracklib.so 승인되기 전에 보안 암호에 대한 테스트를 통과해야 한다.

session  required  pam_unix.so

/var/log/secure 파일에 각 세션의 시작과 끝에 사용자 이름과 서비스 유형을 기록한다. 이 모듈은 추가 기능을 위해 다른 세션 모듈과 겹침으로써 보완 될수 있다.

- pam.d/other

PAM에서 별도로 지정하지 않은 서비스에 대한 인증을 위해 참조하는 파일이다. 

#%PAM-1.0 auth     required       pam_deny.so account  required       pam_deny.so password required       pam_deny.so session  required       pam_deny.so

어떤 것이든 deny (거부) 한다.