CVS log for src/lib/libpam/modules/pam_krb5/pam_krb5.c

Up to [cvs.NetBSD.org] / src / lib / libpam / modules / pam_krb5

Request diff between arbitrary revisions

Keyword substitution: kv
Default branch: MAIN

Pull up following revision(s) (requested by riastradh in ticket #1898):

	lib/libpam/modules/pam_krb5/pam_krb5.c: revision 1.32

pam_krb5: Fix PR lib/57631.

Loose ends in the fix for NetBSD-SA2023-006 that weren't caught by
review or, somehow, by my own testing.  Evidently we need automatic
tests for this pam business.

Pull up following revision(s) (requested by riastradh in ticket #1734):

	lib/libpam/modules/pam_krb5/pam_krb5.c: revision 1.32

pam_krb5: Fix PR lib/57631.

Loose ends in the fix for NetBSD-SA2023-006 that weren't caught by
review or, somehow, by my own testing.  Evidently we need automatic
tests for this pam business.

Pull up following revision(s) (requested by riastradh in ticket #380):

	lib/libpam/modules/pam_krb5/pam_krb5.c: revision 1.32

pam_krb5: Fix PR lib/57631.

Loose ends in the fix for NetBSD-SA2023-006 that weren't caught by
review or, somehow, by my own testing.  Evidently we need automatic
tests for this pam business.

pam_krb5: Fix PR lib/57631.

Loose ends in the fix for NetBSD-SA2023-006 that weren't caught by
review or, somehow, by my own testing.  Evidently we need automatic
tests for this pam business.

XXX pullup-10
XXX pullup-9
XXX pullup-8

Pull up following revision(s) (requested by riastradh in ticket #1844):

	lib/libpam/modules/pam_krb5/pam_krb5.c: revision 1.31
	lib/libpam/modules/pam_krb5/pam_krb5.8: revision 1.13

pam_krb5: Refuse to operate without a key to verify tickets.

New allow_kdc_spoof overrides this to restore previous behaviour
which was vulnerable to KDC spoofing, because without a host or
service key, pam_krb5 can't distinguish the legitimate KDC from a
spoofed one.

This way, having pam_krb5 enabled isn't dangerous even if you create
an empty /etc/krb5.conf to use client SSO without any host services.

Perhaps this should use krb5_verify_init_creds(3) instead, and
thereby respect the rather obscurely named krb5.conf option
verify_ap_req_nofail like the Linux pam_krb5 does, but:
- verify_ap_req_nofail is default-off (i.e., vulnerable by default),
- changing verify_ap_req_nofail to default-on would probably affect
  more things and therefore be riskier,
- allow_kdc_spoof is a much clearer way to spell the idea,
- this patch is a smaller semantic change and thus less risky, and
- a security change with compatibility issues shouldn't have a
  workaround that might introduce potentially worse security issues
  or more compatibility issues.

Perhaps this should use krb5_verify_user(3) with secure=1 instead,
for simplicity, but it's not clear how to do that without first
prompting for the password -- which we shouldn't do at all if we
later decide we won't be able to use it anyway -- and without
repeating a bunch of the logic here anyway to pick the service name.

References about verify_ap_req_nofail:
- mit-krb5 discussion about verify_ap_req_nofail:
  https://mailman.mit.edu/pipermail/krbdev/2011-January/009778.html
- Oracle has the default-secure setting in their krb5 system:
  https://docs.oracle.com/cd/E26505_01/html/E27224/setup-148.html
  https://docs.oracle.com/cd/E26505_01/html/816-5174/krb5.conf-4.html#REFMAN4krb5.conf-4
  https://docs.oracle.com/cd/E19253-01/816-4557/gihyu/
- Heimdal issue on verify_ap_req_nofail default:
  https://github.com/heimdal/heimdal/issues/1129

Pull up following revision(s) (requested by riastradh in ticket #1652):

	lib/libpam/modules/pam_krb5/pam_krb5.c: revision 1.31
	lib/libpam/modules/pam_krb5/pam_krb5.8: revision 1.13

pam_krb5: Refuse to operate without a key to verify tickets.

New allow_kdc_spoof overrides this to restore previous behaviour
which was vulnerable to KDC spoofing, because without a host or
service key, pam_krb5 can't distinguish the legitimate KDC from a
spoofed one.

This way, having pam_krb5 enabled isn't dangerous even if you create
an empty /etc/krb5.conf to use client SSO without any host services.

Perhaps this should use krb5_verify_init_creds(3) instead, and
thereby respect the rather obscurely named krb5.conf option
verify_ap_req_nofail like the Linux pam_krb5 does, but:
- verify_ap_req_nofail is default-off (i.e., vulnerable by default),
- changing verify_ap_req_nofail to default-on would probably affect
  more things and therefore be riskier,
- allow_kdc_spoof is a much clearer way to spell the idea,
- this patch is a smaller semantic change and thus less risky, and
- a security change with compatibility issues shouldn't have a
  workaround that might introduce potentially worse security issues
  or more compatibility issues.

Perhaps this should use krb5_verify_user(3) with secure=1 instead,
for simplicity, but it's not clear how to do that without first
prompting for the password -- which we shouldn't do at all if we
later decide we won't be able to use it anyway -- and without
repeating a bunch of the logic here anyway to pick the service name.

References about verify_ap_req_nofail:
- mit-krb5 discussion about verify_ap_req_nofail:
  https://mailman.mit.edu/pipermail/krbdev/2011-January/009778.html
- Oracle has the default-secure setting in their krb5 system:
  https://docs.oracle.com/cd/E26505_01/html/E27224/setup-148.html
  https://docs.oracle.com/cd/E26505_01/html/816-5174/krb5.conf-4.html#REFMAN4krb5.conf-4
  https://docs.oracle.com/cd/E19253-01/816-4557/gihyu/
- Heimdal issue on verify_ap_req_nofail default:
  https://github.com/heimdal/heimdal/issues/1129

Pull up following revision(s) (requested by riastradh in ticket #206):

	lib/libpam/modules/pam_krb5/pam_krb5.c: revision 1.31
	lib/libpam/modules/pam_krb5/pam_krb5.8: revision 1.13

pam_krb5: Refuse to operate without a key to verify tickets.

New allow_kdc_spoof overrides this to restore previous behaviour
which was vulnerable to KDC spoofing, because without a host or
service key, pam_krb5 can't distinguish the legitimate KDC from a
spoofed one.

This way, having pam_krb5 enabled isn't dangerous even if you create
an empty /etc/krb5.conf to use client SSO without any host services.

Perhaps this should use krb5_verify_init_creds(3) instead, and
thereby respect the rather obscurely named krb5.conf option
verify_ap_req_nofail like the Linux pam_krb5 does, but:
- verify_ap_req_nofail is default-off (i.e., vulnerable by default),
- changing verify_ap_req_nofail to default-on would probably affect
  more things and therefore be riskier,
- allow_kdc_spoof is a much clearer way to spell the idea,
- this patch is a smaller semantic change and thus less risky, and
- a security change with compatibility issues shouldn't have a
  workaround that might introduce potentially worse security issues
  or more compatibility issues.

Perhaps this should use krb5_verify_user(3) with secure=1 instead,
for simplicity, but it's not clear how to do that without first
prompting for the password -- which we shouldn't do at all if we
later decide we won't be able to use it anyway -- and without
repeating a bunch of the logic here anyway to pick the service name.

References about verify_ap_req_nofail:
- mit-krb5 discussion about verify_ap_req_nofail:
  https://mailman.mit.edu/pipermail/krbdev/2011-January/009778.html
- Oracle has the default-secure setting in their krb5 system:
  https://docs.oracle.com/cd/E26505_01/html/E27224/setup-148.html
  https://docs.oracle.com/cd/E26505_01/html/816-5174/krb5.conf-4.html#REFMAN4krb5.conf-4
  https://docs.oracle.com/cd/E19253-01/816-4557/gihyu/
- Heimdal issue on verify_ap_req_nofail default:
  https://github.com/heimdal/heimdal/issues/1129

pam_krb5: Refuse to operate without a key to verify tickets.

New allow_kdc_spoof overrides this to restore previous behaviour
which was vulnerable to KDC spoofing, because without a host or
service key, pam_krb5 can't distinguish the legitimate KDC from a
spoofed one.

This way, having pam_krb5 enabled isn't dangerous even if you create
an empty /etc/krb5.conf to use client SSO without any host services.

Perhaps this should use krb5_verify_init_creds(3) instead, and
thereby respect the rather obscurely named krb5.conf option
verify_ap_req_nofail like the Linux pam_krb5 does, but:

- verify_ap_req_nofail is default-off (i.e., vulnerable by default),
- changing verify_ap_req_nofail to default-on would probably affect
  more things and therefore be riskier,
- allow_kdc_spoof is a much clearer way to spell the idea,
- this patch is a smaller semantic change and thus less risky, and
- a security change with compatibility issues shouldn't have a
  workaround that might introduce potentially worse security issues
  or more compatibility issues.

Perhaps this should use krb5_verify_user(3) with secure=1 instead,
for simplicity, but it's not clear how to do that without first
prompting for the password -- which we shouldn't do at all if we
later decide we won't be able to use it anyway -- and without
repeating a bunch of the logic here anyway to pick the service name.

References about verify_ap_req_nofail:
- mit-krb5 discussion about verify_ap_req_nofail:
  https://mailman.mit.edu/pipermail/krbdev/2011-January/009778.html
- Oracle has the default-secure setting in their krb5 system:
  https://docs.oracle.com/cd/E26505_01/html/E27224/setup-148.html
  https://docs.oracle.com/cd/E26505_01/html/816-5174/krb5.conf-4.html#REFMAN4krb5.conf-4
  https://docs.oracle.com/cd/E19253-01/816-4557/gihyu/
- Heimdal issue on verify_ap_req_nofail default:
  https://github.com/heimdal/heimdal/issues/1129

libpam: remove stray semicolon

No binary change.

lib/libpam: Fix the possible -Werror=stringop-truncation

Replace strncpy(3) with the safer strlcpy(3) and adjust the code.

Error was reported when build.sh was run with MKLIBCSANITIZER=yes flag.

Reviewed by: kamil@, christos@

Merge changes from current as of 20200406

there is no potential overflow anymore (thanks Kamil)

stop using sprintf and check for buffer overflow.

Rebase to HEAD as of a few days ago.

sync with head.

for a reference, the tree before this commit was tagged
as yamt-pagecache-tag8.

this commit was splitted into small chunks to avoid
a limitation of cvs.  ("Protocol error: too many arguments")

avoid using freed pointers and non-format strings

- make log_krb5 varyadic
- centralize error handling to one function
- check for NULL context

Remove use of functions marked as deprecated in Heimdal.

Fix misplaced parenthesis, from henning.petersen@t-online.de, thanks.

Sync with HEAD.

Third (and last) commit. See http://mail-index.netbsd.org/source-changes/2009/05/13/msg221222.html

consistency in password prompt setting code (and with ssh)

sync with HEAD

Fix compilation

off by one, reported by jukka salmi.

PR/35968: Jukka Salmi: add option to pam_krb5(8) to request renewable tickets

Apply patch (request by ghen in ticket #1617):
Update OpenPAM to 20050616 ("Figwort") and add the pam_afslog(8)
authentication module.

init the syslog data.

use the re-entrant syslog functions so that we don't depend on the syslog
settings of the calling program.

Coverity CID 3783: Fix uninit variable.

Coverity CID 3677: Plug memory leak

Coverity CID 1909: Prevent memory leak.

Coverity CID 2480: Move variable initialization higher up to prevent
uninitialized access during error cleanup.

Coverity CID 2481: Move initialization of variable higher up to prevent
uninitialized access in error path.

Coverity CID 2595: Don't call cc_destroy after cc_close because cc_close
free's the second argument.

Implement PAM_REFRESH_CRED / PAM_REINITIALIZE_CRED
support in pam_sm_setcred()

With this and a suitably pam-aware screen locker (eg xscreensaver built
with PAM), you now get the nice Windows-style behavior of having
your tickets refreshed (and tokens, with pam_afslog) when you unlock
your screen.

Pull up revision 1.9 (requested by lukem in ticket #539):
getpw*_r() may return 0 and set pwd==NULL

Pull up revision 1.8 (requested by lukem in ticket #539):
check for pwd != in getpw*_r functions.

getpw*_r() may return 0 and set pwd==NULL

check for pwd != in getpw*_r functions.

Pull up revision 1.7 (requested by thorpej in ticket #96):
Use getpwnam_r().

Use getpwnam_r().

Place some limits on the creds acquired for password change.  Other
minor cleanup inspired by passwd(1).

Use the more familar princ@realm style of password prompt.

Check for PAM_PRELIM_CHECK and simply do nothing.  (Did this even work
in FreeBSD?)

Merge PAM20050226.

Import FreeBSD's PAM modules corresponding to the ones we currently
support as of today (20050226).  This brings in some fixes to a few
of the PAM modules.

- NetBSD build glue
- Warning fixes
- RCSID's

- Import freebsd's version of libpam as of today (20041212).
- Did not import opie, passwdqc, tacplus. We need to decide what to do
  with them.
- Imported radius and ssh, although they will not work until we
  import libradius and re-structure our tree to install libssh.

Initial revision