severity 399002 wishlist thanks Peter Palfrader <[EMAIL PROTECTED]> writes:
> Package: libpam-heimdal,libpam-krb5 > Version: 2.4-1 > Severity: normal > Many applications that need to verify user credentials, especially > screensaves like xlock, xscreensaver and friends, no longer run as > root on a standard Debian system. > They still can authenticate using pam_unix (and therefore indirectly > /etc/shadow), because libpam-modules brings a suid root helper tool: > -r-sr-xr-x 1 root root 18000 Oct 23 14:48 /sbin/unix_chkpwd* > I assume that pam_unix uses this when it doesn't have the required > privileges to access /etc/shadow itself. > With kerberos the situation is similar. In order to protect against > certain KDC impersonation attacks one really wants to set > verify_ap_req_nofail to true in krb5.conf. Now, in order to > authenticate pam verifies it can get a proper ticket encrypted to the > local host principal. This verification is only possible when it can > read the pricipal's key, stored in /etc/krb5.keytab. > Of course the keytab usually is read protected, so only when the pam > module is run as root can this step work. > I think that this very step should be delegated to a helper tool similar > in spirit to /sbin/unix_chkpwd. This is really annoying to do with a setuid helper program; it requires saving a separate ticket cache, chowning that ticket cache to root in the helper process, and then validating the ticket. The chown is unfortunate and is something with which one would have to be very careful to avoid security implications of chowning random files to root; I certainly wouldn't want to write that code. My initial inclination is that this is way more effort than it's worth to prevent an attack on screen lock programs and I'm not willing to look at this. I guess I still could possibly be convinced, but it's really unappealing. Only screen lock programs are really the difficult case here; servers that use PAM can easily have their own keytab available with which they can do validation. I'd rather recommend that people who have this concern provide a world-readable keytab for some other, otherwise unprivileged principal and let pam-krb5 do validation against it. Allowing someone to specify an alternate keytab is easy to do and is already on my to-do list. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
