On 02/27/2014 04:03 PM, 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 

SSSD will do catching and storing password only if configured and if the system can't connect to the central server so potentially a bad root admin can configure SSSD to store passwords and then lure other users to connect to the box and while the box is not connected to the central server passwords will be local and root would be able to steal them and impersonate uses. But I would argue that in this case root can just add some other module to the pam stack that would dump passwords for any user who uses pam stack regardless whether SSSD is in the picture or not so it is not SSSD problem and I do not think it can be generally solved with the software. It is the point where you cross the line into physical security and organization's security and trust policies.



This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 

Freeipa-users mailing list

Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.

Looking to carve out IT costs?

Freeipa-users mailing list

Reply via email to