-
Notifications
You must be signed in to change notification settings - Fork 9
- 5.11.4. Setting Up Polyinstantiated Directories
-
PAM_NAMESPACE(8)
: Needs to be "the last line for session"- From 6.22. pam_namespace: "as the last line for session group"
-
pam_namespace
breaks SSH X11 forwarding, because/tmp/.X11-unix/X*
does not exist for regular users. See Red Hat Bugzilla – Bug 598671. - It might also break some Kerberos stuff, as user's tickets aren't in
/tmp
anymore from whererpc.gssd
(which is running asroot
) tries to look for them.
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
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.
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.
- 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
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.
This file is supported (or used) only by util-linux
's su
and not shadow
's su
.
/* name of the pam configuration files. separate configs for su and su - */
#define PAM_SRVNAME_SU "su"
#define PAM_SRVNAME_SU_L "su-l"
Comes from util-linux
.
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).
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:
- #995236: libpam-modules: pam_limits.so always overwrites rlimits, contrary to man page and upstream behaviour
- #917374: pam: 027_pam_limits_better_init_allow_explicit_root is having serious negative interactions with systemd 240
- #63230: pam_limits.so adds limits instead of replacing them [PATCH] from Fri, 28 Apr 2000
- #62448: allow explicit limits also for root [PATCH] from Sat, 15 Apr 2000
- Apparently the current
027_pam_limits_better_init_allow_explicit_root
patch is a combination of both #63230 and #62448
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
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
.
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.
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.
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 |
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
.
libpam-google-authenticator
-
/etc/pam.d/su
could be justpam_rootok
&pam_deny
? Enablelastlog
ging from display managerslibpam-cap
- https://www.debian.org/doc/manuals/debian-reference/ch04.en.html
- http://linux-pam.org/Linux-PAM-html/Linux-PAM_SAG.html
- https://wiki.ubuntu.com/PAMConfigFrameworkSpec
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583492
- https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/Reference_Guide/s1-pam-sample-simple.html