Originally posted on She ITs and Giggles blog.
Most of us have been using PAM when authenticating without really thinking about it, but for the few of us that have actually tried to make sense of it, PAM is the partner that always says “no”, unless otherwise stated. It’s the bane of any sysadmin’s existence when it comes to making system x secure, and it becomes a major pain point on and off when I forget about the normal rules of engagement.
Rules of Engagement
Session windows
To engage with PAM in any combative situation, please ensure belts and braces are on, and keep your arms and legs inside the vehicle at all times. Backup the /etc/pam.d/
directory, and make sure that you have one or two non-terminating sessions open on your system – ideally a console, and an ssh session.
The unexpected overwrite
In RHEL/Fedora like systems, PAM is configured to have two main files which are included by the rest of the PAM configuration: /etc/pam.d/system-auth-ac
and /etc/pam.d/password-auth-ac
. Normally, system-auth
and password-auth
in the same /etc/pam.d
directory are links to the above files. authconfig
tools will overwrite the configuration in the files with a suffix of -ac
. This means that if the changes need to be persistent and not overwritten, the symlinks can be set to the new location As follows:
ls -l /etc/pam.d/*-auth lrwxrwxrwx. 1 root root 19 Feb 19 12:57 /etc/pam.d/fingerprint-auth -> fingerprint-auth-ac lrwxrwxrwx. 1 root root 16 Feb 19 12:57 /etc/pam.d/password-auth -> password-auth-ac lrwxrwxrwx. 1 root root 17 Feb 19 12:57 /etc/pam.d/smartcard-auth -> smartcard-auth-ac lrwxrwxrwx. 1 root root 14 Feb 19 12:57 /etc/pam.d/system-auth -> system-auth-ac
[root@node1 pam.d]# rm password-auth rm: remove symbolic link ‘password-auth’? y [root@node1 pam.d]# ln -s password-auth-local password-auth
The Language
When the usual PAM translator (authconfig
) is not enough to achieve the right system authentication, one has to start thinking about communicating directly with it. PAM has four different keywords for controlling authentication with the system:
awk '!/^[#\-]/{print $1}' /etc/pam.d/* | sort | uniq account auth password session
auth
is used for providing some kind of challenge/response (depending on the module) – usually username/password.
account
is used to time or otherwise restrict the user account -i.e. user must use faillock, load all the sssd account requirements etc.
password
is used to update the authtoken associated with the user account. This is mainly used to change passwords and it can be where the rules around local password strength can be formulated.
session
is used to determine what the user needs before they are allowed a session: working home directory, to which system limits apply (open filehandles, number of terminals, etc.), and user keyring.
Each of these keywords has these common modes:
required - if this fails return failure but continue executing anyway [success=ok new_authtok_reqd=ok ignore=ignore default=bad] requisite - if this fails return failure and die (don't even attempt to preauth) [success=ok new_authtok_reqd=ok ignore=ignore default=die] sufficient - this is enough for success and exit if nothing previously has failed [success=done new_authtok_reqd=done default=ignore] optional - we don't care unless this is the only module in the stack associated with this type [success=ok new_authtok_reqd=ok default=ignore]
PAM execution stack
PAM executes everything sequentially unless told otherwise. The following snippet of password-auth-ac
will:
# set environment variables auth required pam_env.so # delay (ms) by this amount if last time this user failed # otherwise if absent check login.defs for specified delay auth required pam_faildelay.so delay=2000000 # check user authentication from the system # try_first_pass - use the password that has already been entered if any # nullok allow - allow blank password auth sufficient pam_unix.so nullok try_first_pass # succeed if uid is greater than 1000 and don't log success to the system log auth requisite pam_succeed_if.so uid >= 1000 quiet_success # deny everything else auth required pam_deny.so
If anything is sufficient and it succeeds then the execution stack exits for the component – i.e. auth successful when local user signs in with username/password.
PAM if statements
PAM doesn’t have very obvious if
statements, but given the right parameters it allows jumps of execution. Below is a way of incorporating an SSSD back-end with PAM to allow users with IdM logins access to the system:
# check if the user is allowed to log in with preauthorisation (i.e. has faillock entries) auth required pam_faillock.so preauth silent audit deny=5 unlock_time=900 # skip two rules if successful # NOTE: default ignore means sufficient # and check if it's a unix user - use the password provided by the auth stack auth [success=2 new_authtok_reqd=done default=ignore] pam_unix.so try_first_pass # if it's not a unix user, then use sssd backend for logging in auth sufficient pam_sss.so forward_pass # otherwise fail auth [default=die] pam_faillock.so authfail audit deny=5 unlock_time=900 # this is the skip step from pam_unix module # it allows for resetting the faillock when necessary auth sufficient pam_faillock.so authsucc audit deny=5 unlock_time=900
The comments in line explain what each module is doing. The execution sequence reminds me a bit of jump statements in assembly language and it helps me to think about them in that manner.
Putting them all together gives us this auth section:
auth required pam_env.so auth required pam_faildelay.so delay=2000000 auth required pam_faillock.so preauth silent audit deny=5 unlock_time=900 auth [success=2 new_authtok_reqd=done default=ignore] pam_unix.so try_first_pass auth sufficient pam_sss.so forward_pass auth [default=die] pam_faillock.so authfail audit deny=5 unlock_time=900 auth sufficient pam_faillock.so authsucc audit deny=5 unlock_time=900 auth required pam_deny.so
If we were to make slight adjustments to the above snippet, it may have the frightening effect of allowing users to log in without having the correct password:
auth required pam_env.so auth required pam_faildelay.so delay=2000000 auth required pam_faillock.so preauth silent audit deny=5 unlock_time=900 # reducing this number from 2 to 1 (success=1) auth [success=1 new_authtok_reqd=done default=ignore] pam_unix.so try_first_pass auth sufficient pam_sss.so forward_pass # swapping these two lines auth sufficient pam_faillock.so authsucc audit deny=5 unlock_time=900 auth [default=die] pam_faillock.so authfail audit deny=5 unlock_time=900 auth required pam_deny.so
Conclusion
PAM is a very powerful, yet quite obscure tool. It can be configured to allow people in without even a valid password, or it can deny everyone access apart from every alternate Tuesday between 19:00 and 20:00 (in combination with other tools). Whenever I have configured it, I have found it useful to test for access allowed, access denied, and access locked in order to ensure predictable operation.
Connect with Red Hat Services
Learn more about Red Hat Consulting
Learn more about Red Hat Training
Learn more about Red Hat Certification
Subscribe to the Training Newsletter
Follow Red Hat Services on Twitter
Follow Red Hat Open Innovation Labs on Twitter
Like Red Hat Services on Facebook
Watch Red Hat Training videos on YouTube
Follow Red Hat Certified Professionals on LinkedIn
저자 소개
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
오리지널 쇼
엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리
제품
- Red Hat Enterprise Linux
- Red Hat OpenShift Enterprise
- Red Hat Ansible Automation Platform
- 클라우드 서비스
- 모든 제품 보기
툴
체험, 구매 & 영업
커뮤니케이션
Red Hat 소개
Red Hat은 Linux, 클라우드, 컨테이너, 쿠버네티스 등을 포함한 글로벌 엔터프라이즈 오픈소스 솔루션 공급업체입니다. Red Hat은 코어 데이터센터에서 네트워크 엣지에 이르기까지 다양한 플랫폼과 환경에서 기업의 업무 편의성을 높여 주는 강화된 기능의 솔루션을 제공합니다.