☰

사용자 정의 PAM 모듈 및 보안 고려 사항

tag-icon • tag-icon security authentication pam
사용자 정의 PAM 모듈 및 보안 고려 사항

저는 개발 중인 애플리케이션의 일부가 될 자체 PAM 모듈을 작성하고 있지만 정확히 어디에 배치해야 할지 모르겠습니다. 내 모듈은 기본적으로 LDAP(물론 다른 mojo도 포함)와 유사한 네트워크 수준 인증을 수행합니다.

내 디렉토리에 많은 구성 파일이 있고 /etc/pam.d/대부분의 서비스가 어떤 용도로 사용되는지 알고 있습니다(atd, polkit, ppp와 같은 일부 서비스 제외). 나는 PAM 스택의 인증이 다음과 같다고 가정합니다:

  1. 서비스 이름을 기반으로 스택 실행(구성 파일이 있는 경우)
  2. 인증되지 않은 경우 common-*를 사용합니다. 여기서 *는 모듈 유형(인증, 계정 등)입니다.
  3. 호출 애플리케이션에 성공 또는 실패를 반환합니다(물론 다른 데이터와 함께).

내 가정이 맞나요? 모든 플랫폼에 걸쳐 공통 인증, 공통 계정, 공통 비밀번호 및 공통 세션이 있습니까?

sufficient그렇다면 장애 발생 시 일반 PAM 스택이 영향을 받지 않도록 common-* 위에 모듈로 배치하는 것을 고려 중입니다 . 소프트웨어가 설치될 때 프로그래밍 방식으로 이 작업을 수행할 수 있기 때문에 이는 특히 유리합니다.

잠재적인 보안 취약점을 놓쳤습니까?

사용자 정의 PAM 모듈을 통합할 위치나 모듈 배치 위치와 관련된 보안 문제에 대한 좋은 문서를 찾을 수 없습니다.

답변1

일부 인증 프로세스를 위해 Linux-PAM을 호출하면 항상 단 하나의 스택만 실행됩니다.

다음 위치에서 스택 정의를 찾으십시오. 첫 번째 성공적인 시도에 따라 읽을 파일이 결정됩니다.

  1. /etc/pam.d애플리케이션 "서비스 이름"(예: sshd또는 gdm)의 이름을 딴 파일, 또는

  2. /etc/pam.d/other서비스별 파일이 없는 경우 서비스별 파일, 또는

  3. /etc/pam.conf/etc/pam.d디렉터리가 존재하지 않는 경우 파일입니다.

기능에 대한 설명서를 참조하세요.pam_start더 알아보기.

common-* 파일은 많은 Linux 배포판에서 따르는 규칙이지만 PAM 소프트웨어 자체에서는 필요하지 않습니다. 일반적으로 다른 PAM 파일에 명령문으로 포함됩니다 @include . 예를 들어 /etc/pam.d/otherDebian의 파일에는 다음 내용이 있습니다.

# We fall back to the system default in /etc/pam.d/common-*
@include common-auth
@include common-account
@include common-password
@include common-session

서비스별 파일에도 동일한 명령문을 사용할 수 있으며 @include실제로 해당 파일은 다음 위치에 있습니다.기본데비안에서의 구성. 이는 구성 문제입니다. 시스템 관리자는 /etc/pam.dcommon-* 파일이 전혀 포함되지 않도록 파일을 자유롭게 변경할 수 있습니다!

따라서 PAM 모듈이 애플리케이션에 특정한 경우 애플리케이션별 서비스 파일을 생성하고 거기에서 모듈을 호출하십시오. 하다아니요다른 서비스의 PAM 파일이나 백업 others파일에 모듈을 자동으로 추가합니다. 이렇게 하면 시스템에 설치된 다른 응용 프로그램이 중단될 수 있습니다. PAM 소프트웨어 스택 관리는 애플리케이션 개발자가 아닌 시스템 관리자의 작업입니다.

관련 정보