On 8/18/2018 6:46 PM, Prasad K. Dharmasena wrote: > pam_afs_session "nopag" should be used in conjunction with USM. > > > If no PAG is set, the 'two advantages' described > in http://docs.openafs.org/Reference/1/pagsh.html go away. > Specifically, this part "If the credential structure is identified by a > UNIX UID rather than a PAG, then the local superuser root can assume a > UNIX UID and use any tokens associated with that UID." is unacceptable > for us. Traditionally, we've had departmental admins and lab managers > who have root access to machines but no rights to users' AFS > directories. I believe, this is the point you made in the > systemd/issues thread. > > So, we must pick our poison? A: live w/o '"systemctl --user" and all > that stuff' or B: pam_afs_session with 'nopag'
There are a couple of issues here. First, the OpenAFS pagsh man page makes a claim that cannot be enforced. The local "root" user is capable of: * installing kernel modules * debugging any process on the system and can therefore . execute code in any process context . read memory . write memory . start new processes in any process context In the legacy PAG implementation that makes use of special group identifiers, the "root" user can change the group assignment of any process. Even if PAGs were a strong security boundary, as long as "root" can load kernel modules and debug arbitrary processes, the "root" user can simply read the tokens accessible to a process via the GetTokens ioctl. At best PAGs provide the capability for separate processes running as the same UID to execute with a different set of AFS identities. Creating separate PAGs for each session by default is incompatible with "systemd --user". PAGs can still be used to transition to a separate AFS identity for administrative operations. Please do not make assumptions that AFS PAGs can somehow protect end users from trusted administrators who choose to violate that trust or whose accounts have been compromised. Jeffrey Altman
<<attachment: jaltman.vcf>>
smime.p7s
Description: S/MIME Cryptographic Signature
