MAKELINKLIB that follows MKLINKLIB but can be overwritten by Makefiles
MAKESTATICLIB that follows MKSTATICLIB but can be overwritten by Makefiles
LINKINSTALL that follows MAKELINKLIB but can be overwritten by Makefiles
These give enough control to the module Makefiles so that they don't need
to override the default library install rules which break the debug sets.
- Remove /usr/libexec/named which duplicated /usr/lib/named
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
Otherwise, the default kuserok logic to look at ~targetuser/.k5login
would be blocked by the security measure to thwart NetBSD-SA2023-005.
(There are other ways, e.g. setting SYSTEM-K5LOGIN in /etc/krb5.conf
so the file is /etc/k5login.d/user instead of ~user/.k5login, but
that's not the default configuration and there are plenty of
deployments that rely on ~user/.k5login today.)
I reviewed libkrb5 for homedir access checks. There are three:
1. krb5_config_parse_file_multi, called only by:
- verify_krb5_conf -- not relevant
- krb5_config_parse_file -- not used here as far as I can tell,
only by libhdb ldap logic and test code in heimdal
- krb5_set_config_files -- used here only via krb5_init_context,
which is done at this point
2. plugin_get_hosts in krbhst.c, used to look up hosts for KDC I/O,
which shouldn't be happening at this point, so this is almost
certainly unreachable; also it only appears to control whether
some old plugin API can be used, long after we have read the krb5
config controlling which plugins are available, so this is
probably harmless
3. krb5_kuserok, which is the one we want to allow
Note: This will have to be updated again in the next Heimdal update,
which eliminates the global homedir access flag in favour of making
the default per-context homedir access flag conditional on !issuid.
XXX pullup-10
XXX pullup-9
XXX pullup-8
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.htmlhttps://docs.oracle.com/cd/E26505_01/html/816-5174/krb5.conf-4.html#REFMAN4krb5.conf-4https://docs.oracle.com/cd/E19253-01/816-4557/gihyu/
- Heimdal issue on verify_ap_req_nofail default:
https://github.com/heimdal/heimdal/issues/1129
Rename compiler-warning-disable variables from
GCC_NO_warning
to
CC_WNO_warning
where warning is the full warning name as used by the compiler.
GCC_NO_IMPLICIT_FALLTHRU is CC_WNO_IMPLICIT_FALLTHROUGH
Using the convention CC_compilerflag, where compilerflag
is based on the full compiler flag name.
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@
libpam.a fails to load any modules and does not work at all.
At the moment, openpam_load.c at least must be compiled with and without
OPENPAM_STATIC_MODULES for static and shared libraries, respectively.
Therefore, use CSHLIBFLAGS again, in order to build objects for static and
shared libraries separately.
This may be ugly, but seems better for me than adding further hacks in
libpam/libpam/Makefile, which is already complicated enough...
This avoids leaking NO_STATIC_MODULES into the public header, which
has led to considerable confusion and workarounds in pkgrsc.
PR security/39313
PR security/55216
ok christos
There was a formatting issue with mandoc showing the
literal "Ss" macros. I reported this bug to mandoc since groff
didn't have same formatting. It was recommended to simplify
the formatting due to the weird feature.
Note because of this for groff I didn't use the Ux macro but spelled
out UNIX literally for these subsection headers
(since the macro reset the subsection formatting which was why
the Ss macro was repeated before to reactivate it).
GCC_NO_FORMAT_TRUNCATION -Wno-format-truncation (GCC 7/8)
GCC_NO_STRINGOP_TRUNCATION -Wno-stringop-truncation (GCC 8)
GCC_NO_STRINGOP_OVERFLOW -Wno-stringop-overflow (GCC 8)
GCC_NO_CAST_FUNCTION_TYPE -Wno-cast-function-type (GCC 8)
use these to turn off warnings for most GCC-8 complaints. many
of these are false positives, most of the real bugs are already
commited, or are yet to come.
we plan to introduce versions of (some?) of these that use the
"-Wno-error=" form, which still displays the warnings but does
not make it an error, and all of the above will be re-considered
as either being "fix me" (warning still displayed) or "warning
is wrong."
Originally, MKCRYPTO was introduced because the United States
classified cryptography as a munition and restricted its export. The
export controls were substantially relaxed fifteen years ago, and are
essentially irrelevant for software with published source code.
In the intervening time, nobody bothered to remove the option after
its motivation -- the US export restriction -- was eliminated. I'm
not aware of any other operating system that has a similar option; I
expect it is mainly out of apathy for churn that we still have it.
Today, cryptography is an essential part of modern computing -- you
can't use the internet responsibly without cryptography.
The position of the TNF board of directors is that TNF makes no
representation that MKCRYPTO=no satisfies any country's cryptography
regulations.
My personal position is that the availability of cryptography is a
basic human right; that any local laws restricting it to a privileged
few are fundamentally immoral; and that it is wrong for developers to
spend effort crippling cryptography to work around such laws.
As proposed on tech-crypto, tech-security, and tech-userlevel to no
objections:
https://mail-index.netbsd.org/tech-crypto/2017/05/06/msg000719.htmlhttps://mail-index.netbsd.org/tech-security/2017/05/06/msg000928.htmlhttps://mail-index.netbsd.org/tech-userlevel/2017/05/06/msg010547.html
P.S. Reviewing all the uses of MKCRYPTO in src revealed a lot of
*bad* crypto that was conditional on it, e.g. DES in telnet... That
should probably be removed too, but on the grounds that it is bad,
not on the grounds that it is (nominally) crypto.
christos