Kerberos API - enhancing program to *force* authentication

[Russ Allbery]

Matt Garman <matthew.garman at 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 (eagle at eyrie.org)              <http://www.eyrie.org/~eagle/>