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

Reply via email to