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". 
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
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
Looking to carve out IT costs?
Freeipa-users mailing list