Skip to content

PAM

Jump to bottom Edit New page
pyllyukko edited this page Nov 9, 2024 · 60 revisions

Polyinstation

pam_namespace(sshd:session): open_session - start
pam_namespace(sshd:session): Parsing config file /etc/security/namespace.conf
pam_namespace(sshd:session): Expanded polydir: '/tmp'
pam_namespace(sshd:session): Expanded ruser polydir: '/tmp'
pam_namespace(sshd:session): Expanded instance prefix: '/tmp/tmp-inst/'
pam_namespace(sshd:session): Expanded polydir: '/var/tmp'
pam_namespace(sshd:session): Expanded ruser polydir: '/var/tmp'
pam_namespace(sshd:session): Expanded instance prefix: '/var/tmp/tmp-inst/'
pam_namespace(sshd:session): Configured poly dirs:
pam_namespace(sshd:session): dir='/tmp' iprefix='/tmp/tmp-inst/' meth=3
pam_namespace(sshd:session): override user 0
pam_namespace(sshd:session): dir='/var/tmp' iprefix='/var/tmp/tmp-inst/' meth=3
pam_namespace(sshd:session): override user 0
pam_namespace(sshd:session): Set up namespace for pid 2676
pam_namespace(sshd:session): Checking for ns override in dir /tmp for uid 1000
pam_namespace(sshd:session): Need poly ns for user 1000 for dir /tmp
pam_namespace(sshd:session): The / mount point was marked as slave
pam_namespace(sshd:session): Checking for ns override in dir /tmp for uid 0
pam_namespace(sshd:session): Checking for ns override in dir /tmp for uid 1000
pam_namespace(sshd:session): Setting poly ns for user 1000 for dir /tmp
pam_namespace(sshd:session): Set namespace for directory /tmp
pam_namespace(sshd:session): poly_name pi
pam_namespace(sshd:session): instance_dir /tmp/tmp-inst/pi
pam_namespace(sshd:session): Protect mount of /tmp/tmp-inst over itself
pam_namespace(sshd:session): Checking for ns override in dir /var/tmp for uid 0
pam_namespace(sshd:session): Checking for ns override in dir /var/tmp for uid 1000
pam_namespace(sshd:session): Setting poly ns for user 1000 for dir /var/tmp
pam_namespace(sshd:session): Set namespace for directory /var/tmp
pam_namespace(sshd:session): poly_name pi
pam_namespace(sshd:session): instance_dir /var/tmp/tmp-inst/pi
pam_namespace(sshd:session): Protect mount of /var/tmp/tmp-inst over itself
pam_namespace(sshd:session): namespace setup ok for pid 2676

pwhistory

pwhistory is a bit problematic in Debian when e.g. ldap is also used. As the man page says: "In general, it does not make much sense to use this module in conjunction with NIS or LDAP, since the old passwords are stored on the local machine and are not available on another machine for password history checking.".

pam-auth-update will write the following:

password        requisite                       pam_passwdqc.so 
password        required                        pam_pwhistory.so use_authtok debug
password        [success=2 default=ignore]      pam_unix.so obscure use_authtok try_first_pass sha512
password        [success=1 default=ignore]      pam_ldap.so minimum_uid=1000 try_first_pass

So that means pwhistory is in use with the LDAP module. It would be better to use the remember option with pam_unix, as then it would apply only to local accounts.

pam_krb5

https://www.eyrie.org/~eagle/software/pam-krb5/

If pam_krb5 comes after pam_unix (and others) you will want to use use_first_pass (instead of try_first_pass) or the pam_krb5 will prompt for the password again.

pam_loginuid.so

  • For auditd
  • "This PAM module should only be used for entry point applications like: login, sshd, gdm, vsftpd, crond and atd."

If the loginuid is immutable you might experience problems e.g. in a scenario where you login via SSH, then sudo to root and restart your SSH daemon in a non-systemd system. When you do this the loginuid of sshd gets set to that of the user who logged in with SSH and sshd is unable to change loginuid upon further logins. When PAM is configured with session required pam_loginuid.so the logins will fail and you're unable to login at all. For a better explanation see this post in Stack Exchange.

If this happens you can see pam_loginuid failing in your logs:

sshd[17265]: pam_loginuid(sshd:session): Error writing /proc/self/#uid: Operation not permitted
sshd[17265]: pam_loginuid(sshd:session): set_loginuid failed

/etc/pam.d/sudo-i

Sudo needs to be compiled with --with-pam-login that "allows for a separate pam configuration for sudo's initial login mode" as stated in INSTALL.md.

/etc/pam.d/su-l

  • This file is supported (or used) only by util-linux's su and not shadow's su
  • See su-common.c 
/* name of the pam configuration files. separate configs for su and su -  */
#define PAM_SRVNAME_SU "su"
#define PAM_SRVNAME_SU_L "su-l"

SU(1) (from util-linux):

/etc/pam.d/su-l
    PAM configuration file if --login is specified

/etc/pam.d/remote

LOGIN(1):

-h
    Used by other servers (such as telnetd(8) to pass the name of the remote host to login so that it can be placed in utmp and wtmp. Only the
    superuser is allowed use this option.

    Note that the -h option has an impact on the PAM service name. The standard service name is login, but with the -h option, the name is remote.
    It is necessary to create proper PAM config files (for example, /etc/pam.d/# and /etc/pam.d/remote).

http://ftp.slackware.com/pub/slackware/slackware64-15.0/ChangeLog.txt:

Tue Oct 17 19:34:56 UTC 2023
patches/packages/util-linux-2.37.4-x86_64-2_slack15.0.txz:  Rebuilt.
  Copy /etc/pam.d/# to /etc/pam.d/remote. This is needed for /bin/#'s
  '-h' option, used (for example) by telnetd. If -h is used without
  /etc/pam.d/remote, pam will not be configured properly, and /etc/securetty
  will be ignored, possibly allowing root to login from a tty that is not
  considered secure. Of course, the usual disclaimers about the security of
  telnet/telnetd apply.
  Thanks to HytronBG and Petri Kaukasoina.
  (* Security fix *)

pam_limits

Debian

Do note that pam_limits & limits.conf behaves differently for the root user in Debian because of 027_pam_limits_better_init_allow_explicit_root patch.

The man page says:

NOTE: group and wildcard limits are not applied to the root user. To set a limit for the root user, this field must contain the literal username root.

Somewhat related Debian bugs:

Here is the changelog entry:

pam (0.72-8) frozen unstable; urgency=low

  • Build depends added in previous version, closes: #60817, #61439
  • Allow use of ":0" in group.conf, closes: #61966
  • Added syslog entry to notify that a user succesfully changed their password, closes: #61724
  • Make pam_unix compatible with HP-UX style NIS+ password information, patch from ldaffner@rsn.hp.com, closes: #61942
  • If "audit" is not enabled, don't let pam_unix print the names of unknown users for auth attempts, closes: #61942
  • Fixed ttyname() parsing in pam_access to match that of the old shadow access.conf s,/dev/,, closes: #61644
  • Set some sane defaults for pam_limits.so instead of carrying over potentially bad defaults, patch from Peter Paluch peterp@frcatel.fri.utc.sk closes: #63230
  • Allow explicit (e.g. specified specifically for) limits for root, patch from Topi Miettinen Topi.Miettinen@nic.fi, closes: #62448
  • Added information to time.conf about logoutd, which is now enabled via this file.
  • cracklib maintainer claims this isn't a bug, closes: #54180
  • fixed control syntax handling which was causing segfaults, closes: #62237

-- Ben Collins bcollins@debian.org Sat, 29 Apr 2000 11:39:59 -0400

nproc and root

The man page for setrlimit states the following for RLIMIT_NPROC:

This is a limit on the number of extant process (or, more precisely on Linux, threads) for the real user ID of the calling process. So long as the current number of processes belonging to this process's real user ID is greater than or equal to this limit, fork(2) fails with the error EAGAIN.

The RLIMIT_NPROC limit is not enforced for processes that have either the CAP_SYS_ADMIN or the CAP_SYS_RESOURCE capability.

Apparently this holds true, as if you take a root shell, check it's PID and run prlimit --nproc=0 for that PID it doesn't seem to affect anything. Except the output of ulimit -u.

/usr/share/pam-configs

tally2

TODO: DEPRECATED

The auth part needs to be at the top of the primary block, as if pam_unix fails, it calls requisite pam_deny and the execution of the stack stops and the failed attempt doesn't get counted. The priority is set to 257, so it would be just above pam_unix and others.

The account part doesn't seem to be needed, but is added just in case. Adding it to the additional block should be sufficient. As it's function is to deny access in case of failed logins, it is executed if some other module doesn't block the access before. End result is the same -> no access.

ACCOUNT OPTIONS
    Account phase resets attempts counter if the user is not magic root. This phase can be used optionally for services which don't call
    pam_setcred(3) correctly or if the reset should be done regardless of the failure of the account phase of other modules.

lastlog

By default, lastlog is only enabled in login. SSH (apparently) updates the log file by itself. This is added, so that logins from display managers will also be in the list and also that SSH would report failed logins:

Last login: Thu Jan 11 00:14:21 EET 2018 from 1.2.3.4 on pts/2
Last failed login: Thu Jan 11 00:14:32 EET 2018 from 1.2.3.4 on ssh:notty
There was 1 failed login attempt since the last successful login.

If lastlog is added to common-session-noninteractive, PAM sessions from cron also get logged.

root             cron                      Sat Jan 13 12:17:01 +0200 2018
daemon           cron                      Sat Jan 13 11:43:01 +0200 2018
bin              cron                      Sat Jan 13 11:43:01 +0200 2018

Not having lastlog in common-session-noninteractive stops sudo lastlogging also.

btmp

When pam_lastlog displays failed logins it reads the btmp file. Unfortunately it's up to the authenticating software to log failed logins to btmp and not all programs do this. Here is incomplete table about which programs log these and which don't:

Program Logs to btmp
sudo No
OpenSSH Yes
login Yes
su (shadow) No?
su (util-linux) Yes (log_btmp())
Dovecot No

uid_ge_1000

This configuration prohibits authentication (& account) of system users. In auth it is set as requisite so that system users don't even get to pam_unix. It could be also as required, but it doesn't seem to provide any additional benefit. It would be nice to continue to pam_unix and see the situation where system user password authentication would succeed (shouldn't happen, and would be an anomaly), but pam_unix doesn't log that until session (pam_unix(sshd:session): session opened for user ...).

In addition to auth this also needs to exist in account if the system user is authenticating through sshd with SSH keys, krb5 etc., as in that case PAM auth is not processed by sshd.

TODO

  • libpam-google-authenticator
  • /etc/pam.d/su could be just pam_rootok & pam_deny?
  • Enable lastlogging from display managers
  • libpam-cap

Docs

Add a custom footer
Add a custom sidebar
Clone this wiki locally