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
> 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".  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. 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?
 in sssd upstream. ipa-client-install enables caching credentials.
Freeipa-users mailing list