> 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.

In a Kerberos/IdM/AD environment, the password isn't available except at 
initial sign on. If I sign on using my machine, then ssh to user Evil's 
machine, the worst user Evil can do is steal my TGT, which has a much shorter 
life than a password. If Evil is quick, he can get at my files on the main 
server. But I never give my password to user Evil in this situation, and user 
Evil is not an admin on my box, where he can affect the pam stack.

Thinking this through...This is definitely not a physical security thing: the 
machine was issued to user Evil and Evil must have physical access to it. These 
factors are not amenable to change. The problem is that "risk" and "granting 
power" are two sides of the same coin.  The challenge is to grant useful 
amounts of power while mitigating risk to others. For instance: the above 
description suggests that one way to mitigate risk is to not delegate 
administrative control over machines which handle other people's passwords. 
Whether this is "policy" or just "good practice" is perhaps a matter of 
semantics. Either way: Training the users to do the initial signon on their own 
box will go a long way to eliminating the need for a technical 
control...Definitely not a software problem...

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

Reply via email to