On Thu, Feb 27, 2014 at 09:03:35PM +0000, Nordgren, Bryce L -FS wrote: > > > On Wed, Feb 26, 2014 at 04:24:54PM -0500, Steve Dainard wrote: > > > Would it not be possible for root to disable selinux enforcement? > > It should also be possible to copy private keys out of ~user/.ssh and login > to other machines as "user", assuming no password on the ssh key pair. > > It's probably best to assume that all your client machines are under the > control of knowledgeable, malicious admins, and to put your important > information somewhere other than your client machines. The only real way to > "take back the night" is to force your users to connect to a service you > control using an authentication mechanism you control. (e.g., Kerberos > service tickets: accept no substitute. :) ) Prohibiting them from making any > changes makes you responsible for every last customization. Delegating frees > you up, but requires trust. Probably a good rule of thumb is to be generous > doling out permissions when only one person will ever use the machine. Giving > someone control over someone else's workspace should require consent of the > controlled. > > One thing that is nagging at me: I read that sssd caches your > credentials in a form such that they can be retrieved and provided to your > "organizational system". [1] This seems like a vector for a knowledgeable, > malicious admin to break out of the client machine and impersonate someone > else to any domain service. Is there a safeguard against this?
Caching credentials is disabled by default[1]. Even when credential caching is enabled, the cache is only ever readable by root, the hashes are *never* exposed to the system. FYI, the hash is a salted sha512. What leads you to believe the cached credentials can be retrieved? [1] in sssd upstream. ipa-client-install enables caching credentials. _______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
