PAM - 1

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

시스템 관리자가 응용프로그램들이 사용자를 인증하는 방법을 선택할 수 있도록 해 주는 공유 라이브러리 묶음이다. 즉, 사용자를 인증하고 그 사용자의 서비스에 대한 액세스를 제어하는 모듈화된 방법을 말한다. PAM은 관리자가 응용프로그램들의 사용자 인증 방법을 선택할 수 있도록 해 준다. 필요한 공유 라이브러리의 묶음을 제공하여 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/*

 

1). 계정 모듈(account module)들은 명시된 계정이 현재 조건에서 유효한 인증 목표인지를 검사한다. 이것은 계정 유효기간, 시간 그리고 사용자가 요청된 서비스에 접근 가능한지 같은 조건을 포함한다.

2). 인증 모듈(authentication module)들은 비밀번호를 요청하고 검사하는 것 같이 사용자의 신원을 확인한다. 또한 인증 정보를 keyring 같은 다른 시스템들에게 전달한다.

3). 비밀번호 모듈(password module)들은 비밀번호 갱신을 책임진다. 또한 강력한 비밀번호 강화에도 사용된다.

4). 세션 모듈(session module)들은 세션 시작과 끝에 수행되는 행동을 정의한다. 그 후 사용자는 성공적으로 인증된다.

출처 :https://ko.wikipedia.org/wiki/%EB%A6%AC%EB%88%85%EC%8A%A4_PAM

 

일반적인 과정

1). 사용자나 프로세스가 애플리케이션의 접근(Access)을 요청한다.

2). 해당 애플리케이션의 PAM 설정 파일을 확인한다.

  - 접근정책이 작성되어있다.

  - 접근 정책은 인증 과정에 사용되는 모든 PAM모듈의 리스트를 통해 설정된다.

  - 해당 PAM모듈 리스트를 스택이라고 한다.

3). 스택의 PAM모듈이 리스트상의 순서대로 호출된다.

4). PAM모듈은 성공 또는 실패 상태를 반환(Return)한다.

5). 스택은 계속해서 순서대로 확인되며, 실패 상태를 반환한다해서 중단되지 않는다.

6). 모든 PAM모듈의 상태 결과가 종합되어 전체 인증 과정의 성공 또는 실패 상태를 반환한다.

 

PAM-option

단순 키워드

Context (type)

Control Flag

PAM Module

Module Option

연속된 액션

Context (type)

Return Value + Action

PAM Module

Module Option

 

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 파일을 지정할 때 사용한다.) 다른 컨트롤과 달리 모듈 결과가 처리되는 방식과 관련이 없다. 이 플래그는 지정된 매개 변수와 일치하는 구성 파일의 모든 행을 가져와서 모듈에 인수로 추가한다.

 

3. Return Valuse + Action

Main Return Values

-success[0] : 성공

-user_unknown[10] : 확인되지 않는 사용자

-new_authok_read[12] : 새 인증 정보 요구

-ignore [25] : 모듈 무시

-default : 반환 코드가 없을 경우를 대비한 설정

 

Action

-ignore : 모듈의 결과 값이 응용프로그램이 갖게될 결과 값에 영향을 주지 않는다.

-bad : 이것은 결과 값이 모듈 실패의 표시로 생각해야 한다. 이 모듈이 첫번째로 실패한 모듈이면, 이 상태 값은 전체 모듈의 결과로 사용될 것이다.

-die : bad와 같지만 모듈 수행이 중지되고, PAM이 응용프로그램으로 바로 리턴한다는 점이 다르다.

-ok : 이것은 PAM에게 관리자가 이 결과값이 모듈 전체의 결과 상태로 바로 사용되길 바란다고 알려주는 것이다. 즉, 모듈 목록의 수행과정에서 앞까지의 상태가 PAM_SUCCESS이면, 이 모듈의 결과값은 앞까지의 상태값을 덮었쓴다. 반면 앞까지의 상태가 실패하면 이 'ok'값은 상태를 덮어쓰지 않을 것이다.

 

4. module-path ( 모듈 경로 )

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

 

# cd /lib/security ; ls

 

5. 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 (거부) 한다.

 

※기타

-system-auth/password-auth 차이

RHEL 기준 5.x 이전 버전에서는 system-auth, 6.x 버전 이후에서는 password-auth를 사용한다고 알고있는 경우가 많지만 PAM을 이용하는 서비스별로 인증과 관련된 모듈 참조시 system-auth/password-auth를 쓰는 경우가 각각 다름

예)/etc/pam.d/su 에서는 인증에 대한 모듈로 system-auth를 참조

    /etc/pam.d/sshd 에서는 인증에 대한 모듈로 password-auth를 참조

-required/requisite 차이

required와 requisite 인터페이스 모두 반드시 '성공' 되어야만 PAM을 이용한 인증이 완료되나 보안 및 가용성 측면에서는 분명한 차이가 존재함. required의 경우 실패를 해도 실패한 지점이나 결과값에 대한 리턴을 하지 않는데 requisite의 경우 실패한 지점과 원인을 리턴하기에 보안 관점에서는 공격자에게 인증이 거부된 원인이 제공되며 가용성 측면에서는 실패한 원인을 리턴하여 원인분석을 용이하게 해줌

 

출처 : 5log.tistory.com/183, kimhyun2017.tistory.com/212