As people begin to use confined users, placement of pam_modules in the /etc/pam.d configuration files becomes critical.
# cat /etc/pam.d/gdm
#%PAM-1.0
auth [success=done ignore=ignore default=bad] pam_selinux_permit.so
auth required pam_env.so
auth substack system-auth
auth optional pam_gnome_keyring.so
account required pam_nologin.so
account include system-auth
password include system-auth
session required pam_selinux.so close
session required pam_loginuid.so
session optional pam_console.so
session required pam_selinux.so open
session optional pam_keyinit.so force revoke
session required pam_namespace.so
session optional pam_gnome_keyring.so auto_start
session include system-auth
There are three SELinux pam modules listed in the /etc/pam.d/gdm config file. pam_selinux_permit.so reads /etc/security/sepermit.conf looking for usernames, if found and SELinux is in enforcing mode the user can login without a password. pam_selinux_permit.so is used with the xguest package for kiosk users.
pam_selinux.so is the important module though. pam_selinux.so defines the SELinux user/context that gets assigned to you when you login. pam_selinux.so is called twice within the pam session once with the close parameter and once with the open. Pam session modules are called once when a new session is started/opened and once when the session is ended/closed. So the open parameter tells pam_selinux.so to only execute the open section of the pam_module when this module gets executed. The close indicates to pam_selinux.so only execute the close section of the module.
What does this really do?
pam_selinux.so open uses libselinux functions to setup the security context for all programs to be execed by the "login" process. If I setup a user to login as staff_u, pam_selinux.so open tells the kernel programs execed from the login program from this point forward will be execed as staff_u:staff_r:staff_t . pam_selinux.so close uses the libselinux functions to tell the kernel to go back to the default.. So all pam_modules called on the closing of the session will either run in the login's programs context (gdm_t) or will transition if policy is defined.
While this seems complicated, the important thing to understand is, if you want to add a pam_module that requires special (root) privileges and execs helper apps , it probably needs to be added before pam_selinux.so open, since pam_selinux.so open might be defining a confined user which is not be allowed to to execute the helper applications or the access the helper application requires. pam modules that exec applciations that can be executed by the user or requires knowledge of which SELinux context the user will get assigned need to be defined after pam_selinux open.
session optional pam_keyinit.so force revoke
session required pam_namespace.so
session optional pam_gnome_keyring.so auto_start
session include system-auth
These pam modules all do things that require Selinux user access, or use the context of the user to label objects.
pam_keyinit.so sets up the labeling of the keyring based on the SELinux user context. pam_namespace can mount directories based on the SELinux context pam_gnome_keyring.so executes commands that the user would be allowed to execute and system-auth can execute pam_kerberos, which creates files in /tmp or uses the kernel keyring and would require SELinux context.
session optional pam_console.so
pam_console on the other hand execs /sbin/pam_console_apply which is a privileged application that a confined user would not be allowed to execute, so it needs to be run before pam_selinux open.
If you are going to add a pam_module that would exec commands that the user would not be allowed to execute, for example pam_mount, it should be added before the pam_selinux.so open command. If you are adding a pam_module that execs command a user could execute, then you probably want these after the pam_selinux.so open line.
