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
>>> 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.
for further details on this.
Does it explain the situation?
> 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).
>> Petr^2 Spacek
>>> how to clean it up once you know the host is compromised is the subject
>>> of the other thread.
>>>> 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.
Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project