On 16.11.2016 17:47, Stijn De Weirdt wrote: >>> this is a different question: what can we do such that compromised host >>> can do a little as possible if the admin doesn't (yet) know the host is >>> compromised. >>> >>> the default policy allows way too much. >> >> For any useful advice we need more details. >> >> What are the operations you want to disable? > at the very least, "kvno userlogin" should fail (i.e. access to a host > keytab shouldn't permit retrieval of arbitrary user token).
I think that this is misunderstanding. "kvno userlogin" does not allow the attacker to do anything. The result of kvno command is a service ticket for particular principal (user, host). The attacker can use this service ticket *for authentication to the particular principal* (user, host). So the only thing the attacker can do is to prove its identity to given (user, host). This exactly matches capabilities the attacker already has - the full control over the host. Please see https://en.wikipedia.org/wiki/Kerberos_(protocol)#Client_Service_Request for further details on this. Does it explain the situation? Petr^2 Spacek > > i'm assuming that retrieval of service tokens for another host is > already not possible? (ie if you have keyatb of fqdn1, you shouldn't be > able to retrieve a token for SERVICE/fqdn2@REALM). > > stijn > >> >> Petr^2 Spacek >> >> >>> >>> how to clean it up once you know the host is compromised is the subject >>> of the other thread. >>> >>> stijn >>> >>>> >>>> In the case that the host is compromised/stolen/hijacked, you can >>>> host-disable it to invalidate the keytab stored there but this does not >>>> prevent anyone logged on that host to bruteforce/DOS user accounts by >>>> trying to guess their Kerberos keys by repeated kinit. >>>> >>> >> >> > -- Petr^2 Spacek -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project