Re: /var/heimdal/kpasswdd.history no longer updating after a heimdal upgrade
Toby Blake <t...@inf.ed.ac.uk> writes: > Hi Russ, when you say "the CrackLib code in there is suspect", do you > mean in the current krb5-strength? If so, can you provide details? > Suspect, to the extent that it should not be used? Should it be built > against a newer cracklib? Note that we're using it with MIT kerberos, > so hopefully this isn't off-topic for this list. The code quality of CrackLib (any version) has historically not been very good. I fixed a bunch of corruption bugs in the version embedded in krb5-strength compared to the (at the time) abandoned upstream. But since then someone else took over upstream development and found more bugs. I have mail somewhere in my inbox about them, but I haven't looked at them in any detail for security implications. (Since switching jobs, I haven't been doing much with Kerberos, and haven't had time to chase down a lot of things like that.) The concern for MIT is stronger because it runs directly inside kadmind, so any sort of bug might have immediate security implications. If you have a fairly recent distribution with the new patches, you may want to consider building with system CrackLib instead, or downloading the current version of CrackLib and installing it and then telling krb5-strength that it's the system version and to build with it. You do lose some of the patched-in rules, though. Alternately, you may want to consider switching to the SQLite database approach with a good wordlist. It doesn't do all the complex munging that CrackLib does, but current thinking on password strength is that those munging rules aren't as useful as they used to be. It does generic edit distance one checks from any dictionary word, which we found to be pretty effective. That said, I may be excessively paranoid, since I did hack on the embedded CrackLib until it ran clean under valgrind. That doesn't mean there are no remaining bugs, but I may have already patched or worked around those issues. I'm hoping to find some time over the upcoming long US holiday weekend to try to catch up on some open source stuff. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>
Re: which pam-afs to use
Ted Creedon <tcree...@easystreet.net> writes: > heimdal & openafs are installed but pam_afs_session.so is not > can a pointer to the correct github version be sent? https://github.com/rra/pam-afs-session I have not tested with the new Heimdal, but it would surprise me if it didn't work. Note that the module is known to not work properly with systemd user sessions, and fixing that is going to be difficult (and may be beyond the amount of time I can spend on it, given that I'm no longer using AFS and am only using Kerberos very lightly these days). -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>
Re: Kerberos authentication to load-balanced services in AWS and reverse DNS
Jeffrey Hutzelman <jh...@cmu.edu> writes: > The problem you may be more likely to run into is that the server might > not actually be able to accept tickets for more than one service > principal at a time. That is, it can be configured to accept the > server's own principal name or the shared one, but not both. Cyrus SASL > had this problem for a long time, and I'm not sure it ever got fixed. Originally, we locally patched Cyrus SASL to fix this bug. I don't recall if that was still the case or if we managed to at least get that patch as far upstream as the Debian package. > If you're willing to patch, the fix for that problem is actually pretty > simple -- instead of acquiring GSSAPI acceptor credentials, the server's > call to gss_accept_sec_context() should simply pass GSS_C_NO_CRED in > place of the credential argument. Then the server will accept tickets > for any principal in its keytab. Yup, that was the fix. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>
Re: Re-encrypt on change of master key
"Henry B (Hank) Hotz, CISSP" <hbh...@oxy.edu> writes: > Shut down all daemons on the master. > hprop --decrypt --stdout | hpropd --stdin > Restart all daemons. You probably also want to shut down incremental propagation while you do this. I think this should force a full resync when the slaves reconnect, but it would be a good idea to thoroughly test the replication behavior in a test realm before doing this in a production realm. I forget how it deals with a complete database reload; I think it's supposed to do something sane, but that would be the component that I would worry about. Note that you will need to manually copy the new master key to the slaves before they'll be able to replicate. Also don't forget to keep the old master key around for the length of your backup retention so that you don't invalidate your backups. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>
Re: How to disable DNS lookups?
"Roland C. Dowdeswell" <roland.dowdesw...@twosigma.com> writes: > In the longer term, we should likely stop using getaddrinfo(3) for names > obtained from DNS SRV RRs and directly query DNS for them as this matches > expectations. That is: you wouldn't expect that if you find > _kerberos._udp.my.realm IN SRV 0 0 88 foo.my.realm > that an entry for foo.my.realm in /etc/hosts would then override the > DNS for it. Eh? I *absolutely* would expect that and would consider it a bug if it did not. It is incredibly useful for testing to be able to temporarily override the IP address of a host in /etc/hosts, and I expect all software to honor that. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>
Re: How to disable DNS lookups?
"Roland C. Dowdeswell" <roland.dowdesw...@twosigma.com> writes: > Note that it states "the domain name of the target host". /etc/hosts > doesn't contain domain names but rather host names. The "hostname" in /etc/hosts can contain periods, and it functions like an FQDN in practice. > It also urges implementors to return the address records in the > Additional Data section. This implies, I think, the addresses are to be > obtained by the implementor probably on the domain name server. My understanding is that Additional Data is a performance optimization in DNS that allows a cache to make fewer queries by anticipating some of the questions it's likely to ask next and letting it pre-cache that data. This information is not used by clients under normal circumstances (dig is not a normal client); in fact, some quick searching seems to indicate that it's often not even exposed by DNS libraries. It's used by the cache to answer subsequent queries (or not if you don't bother to make them). Anyway, I think the standard question is a red herring. You cannot look at DNS standards to figure out whether /etc/hosts should override, because of course /etc/hosts isn't mentioned in DNS standards because it's not part of DNS. I think this is pretty clearly implementation-defined. Nothing in any standard is going to tell you that you MUST connect to an address specified in an A or record or you're not doing Kerberos; that's not how standards work. They're going to tell you that, for interop with a site specifying Kerberos KDCs in DNS, this is the IP that the SRV record points to and that you should connect to if you want to honor their DNS records, which is fine; that's not what we're discussing. What we're discussing is whether to maintain what has become a valuable UNIX *debugging and override* tool, which of course isn't in the scope of a Kerberos or DNS standard for the same reason that LD_PRELOAD isn't in the scope of a Kerberos or DNS standard. I do see the point that people can override their /etc/krb5.conf instead, and now that I know about this I suspect I will be able to make my systems do the right thing, but /etc/hosts is convenient because it overrides *all software* (as opposed to making you go hunt down some specific config file for each piece of software). I think not honoring it would be unpleasantly surprising. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>
Re: How to disable DNS lookups?
Russ Allbery <ea...@eyrie.org> writes: > My mental model of how an implementation that uses SRV records works is > that it does a SRV query to find the list of hosts and weights, and then, > for each host in weight order, does a gethostinfo(3) call on that > hostname. Apologies, that of course was supposed to be getnameinfo(3). -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>
Re: How to disable DNS lookups?
Viktor Dukhovni <heim...@dukhovni.org> writes: > The problem is that we don't get: > 1. Look up name from SRV in /etc/hosts, return address(es) if found > 2. Look up same name in DNS, return address(es) if found > instead, in step 2, we may get undesirable, incorrect and/or costly > interactions with the stub resolver's domain search list. The name in > the SRV record is an FQDN and MUST NOT be subject to RES_DEFNAMES or > RES_DNSRCH. The getaddrinfo(3) API provides no means to signal that a > name should not be subjected to the DNS search list. Ah! Thank you. That helps me understand the problem you're trying to solve. How often does this actually come up, though? My understanding of how domain search works is that the record returned by the SRV record would have to not exist *and* some record formed by appending the local domain to the name would have to exist. That seems *extremely* unlikely, although I guess the latter could match local wildcard entries if someone was doing something weird. > Furthermore, if a domain's KDC list is not locally administered, and > you're delegating the KDC names to remotely administered DNS, local > overrides of the address resolution are no less costly than just putting > override kdcs in the [realms] section. Indeed the latter is much less > fragile. Right, the point is not that you can't override with /etc/krb5.conf, the point is that /etc/hosts normally overrides everything without having to hunt down software-specific configuration files. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>
Re: How to disable DNS lookups?
u-hd-p...@aetey.se writes: > On Tue, Jul 25, 2017 at 02:58:29PM -0400, Roland C. Dowdeswell wrote: >> It is counter-intuitive to expect that /etc/hosts will interpose in the >> middle of a lookup. > I second Russ and do not agree with you on this point. > Given that SRV records as a matter of fact are defined via A[AAA] > records, (and given that A lookups historically _are_ interposed by > /etc/hosts) what says that /etc/hosts are to be ignored if an A lookup > happens as a consequence of an SRV one? Yup, agreed. I'm unconvinced by the argument that this is confusing. My mental model of how an implementation that uses SRV records works is that it does a SRV query to find the list of hosts and weights, and then, for each host in weight order, does a gethostinfo(3) call on that hostname. This will, in fact, interpose /etc/hosts with a standard nsswitch configuration. Now, perhaps my mental model is wrong for a given implementation, but (a) the resulting behavior is very useful for testing and something I've used for years, and (b) it's not an *unreasonable* mental model, or particularly confusing. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>
Re: Does pre-authentication help against "insider" attacks?
Adam Lewenberg <ada...@stanford.edu> writes: > I am trying to understand the security benefits of requiring > pre-authentication. > Consider this scenario: an attacker is trying to learn the password for > a service account, e.g., the principal used by the ssh service on some > server. The attacker already has the credentials for a user's account > (but not, of course, the service account he is attacking). The attacker > requests a service ticket for the account he is attacking. The attacker > then uses brute force (offline) to derive the service account's > password. > In the context where the attacker *already* has an account, requiring > pre-authentication does not help mitigate against this sort of attack.In > other words, pre-authentication helps against attacks from "outsiders" > but not from existing users. Assuming the attack is on a principal for which one can obtain service tickets, I believe this is correct. (This is one of the reasons why you should disable service tickets for user accounts unless you have a specific need for user-to-user authentication.) The primary defense against this attack for service accounts is that service accounts should always have a randomly-generated key, not a password, so brute force attacks on a service ticket to recover that key are infeasible (they're equivalent to a brute-force search of the entire key space, which should be large enough to make this impractical). Pre-authentication is primarily there to protect weak keys, such as any keys derived from a password. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>
Re: Cannot get [password_quality] to work with 7.5.0 on Debian buster
Adam Lewenberg writes: > I have a newly-built Debian buster server. I have installed the heimdal > packages that are available in the buster distribution (currently, these > all have version number 7.5.0+dfsg-2). > I have this in /etc/krb5.conf: > [password_quality] > policies = minimum-length > min_length = 10 > When I change the password for a user to one that is one-character long, > kadmin lets me. Here is the command: > % kadmin -p joeuser passwd -p A janeuser > joeu...@stanford.edu's Password: > % (no error shown) > How do I configure it so that heimdal respects the [password_quality] > stanza? Password changes by administrators bypass all password quality checks on Heimdal without https://github.com/heimdal/heimdal/pull/320, which was applied locally to Stanford's build of Heimdal. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>
