You can only use the host key table from a host with the same IP address. The 
server verifies that the IP address corresponds to the hostname. In theory 
someone could bring a laptop and plug it in in place of the original host with 
the same IP address, but that wouldn’t let them compromise anything they 
couldn’t already get if they had root on the original host. We do lots of 
monitoring. If one of our hosts disappears, we’ll notice. If they replace it 
with another host at the same IP address that’s close enough to the original 
that we don’t  notice, it’s not clear what is being compromised. They’re just 
giving us free hardware...

And at least in our situation, we have various groups of systems at different 
security levels. So you could compromise that user on one cluster, but not 
system-wide. 


> On Jul 21, 2017, at 5:55:27 PM, Russ Allbery <ea...@eyrie.org> wrote:
> 
> Russ Allbery <ea...@eyrie.org> writes:
>> Charles Hedrick <hedr...@rutgers.edu> writes:
> 
>>> * A kerberized service where the user registers that they want to be
>>> able to do cron jobs on a given machine.
>>> * A kerberized pam module that calls the same service and gets back
>>> credentials, locked to the IP address, and at least by default not
>>> forwardable.
> 
>> How does this address the problem raised on this thread?  It's still the
>> case that if you become root on the host, you can just steal the keytab
>> used by that daemon and use it anywhere.  This gives you enhanced
>> protection if you trust the boundary between non-root users and root,
>> but not if you don't trust the machine.
> 
> Oh, wait, I see -- it does transform part of the attack to occasional
> on-line, since while you can steal the system keytab and request tickets
> whenever you want, you can't get the long-lived keytab for the actual
> target credential.  (And presumably you can put monitoring and alerting
> around the host keytab being used from unexpected places.)
> 
> Yeah, that's a partial security improvement.
> 
> -- 
> Russ Allbery (ea...@eyrie.org)              
> <https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.eyrie.org%2F~eagle%2F&data=02%7C01%7Chedrick%40rutgers.edu%7Cb553338940c945a517d608d4d08333bf%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636362709304409598&sdata=T8q1NWbN3%2FdXMfTw1%2FpYvQIn%2B3l1YP9X31WIkzncynU%3D&reserved=0>


________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Reply via email to