Matt Garman <matthew.gar...@gmail.com> writes: > Since sending that I basically did exactly what you suggest, more or > less copying the krb5_init source, but stripping out any cache-related > stuff. I also request a very short-lived ticket life (30s). So far > seems pretty straightforward!
Yup, that will work. Note that you're probably skipping krb5_verify_creds, so an attacker that can spoof the KDC on the network can bypass this check, but given the other issues with this security measure, it may not be worth worrying about that. I would recommend considering using PAM to do the authentication instead of hard-coding a Kerberos authentication, since that gives you some more flexibility to, say, plug in a 2FA authentication mechanism instead later on. I think you'd actually get more security from requiring a Yubikey tap to reattach than you're getting from asking for the Kerberos password, and PAM makes it much easier to swap that stuff around. > Oh we violate this on a regular basis! Our Linux environment is all > rackmount servers in a remote facility, and none have keyboards attached > (except in special maintenance situations). But all access is through > ssh, so I believe Kerberos keys (or anything sensitive for that matter) > should never pass through the network un-encrypted. Yeah, it's common. The theoretical risk is that it means a compromise of any server means a compromise of all user accounts that have authenticated on that server since the compromise, which allows lateral movement. If the attacker steals credential caches, they can do that to some extent anyway, but limited by the ticket lifetime. With the long-term keys, the threat is more persistent. The basic idea is that there's really no security system that can get out of having to trust the physical system at which someone is sitting, but you can limit your exposure to lateral movement just to those systems (at least within the lifetime of the ticket cache) by not letting the long-term keys leave those systems. In practice, it's very hard to hold to this, and a more common approach these days is to add a second factor instead, since intercepting someone's second factor via a compromised server doesn't actually help the attacker. > Not currently, but now that you mention it, it's probably time I sit > down and learn it (SELinux that is). To be honest, I've always been > scared of it. It's kind of scary. :) > But: if a root user can drop in a fake binary, can't he also twiddle > the SELinux policy as well? (Exposing my gross ignorance of SELinux > here.) Changing MAC security policies usually requires a reboot, and can be set up to require some other special access (physical console, booting into a rescue environment, etc.). That makes it very hard for an attacker to do that without being detected. > On the other hand, our environment is such that it would be fairly hard > to actually produce a non-desired binary, as Internet access is > basically non-existent, and the vanilla source (tmux or other program) > would be secured in a inaccessible vault. If an attacker can possibly ssh into a system, they can probably get their own tmux binary onto that system. They just cat it over the ssh connection. :) Attackers don't need outbound Internet access. Usually the attacker has to compromise your VPN in some way first, of course, but you're clearly already worrying about attackers who have gotten that far in or you wouldn't bother securing server-side tmux sessions. It's pretty hard to prevent an attacker from bringing in their own binaries without making it impossible for people to do their work. > We acknowledge that there will likely always be holes, just trying to > plug the known ones and set up as many safeguards as possible. Yeah, I'm just not sure this safeguard is that meaningful. But it does depend on your threat model. It's pretty good against a local admin who decides to casually snoop on things but won't be bothered to upload a new tmux binary, since a bit of obscurity will be enough to deter that sort of attacker. It's probably useless against an APT attacker. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
