Purging the agent's security token

Larry O'Leary loleary at redhat.com
Mon Jan 7 18:49:48 UTC 2013


On Tue, 2012-12-18 at 08:49 -0500, Jiri Kremser wrote:
> Hi,
>   I would like to implement this feature Jay originally proposed. The idea is that it should be possible, for the authorized user (MANAGE_SECURITY), to invalidate an existing security token for any reason (mostly agent/db upgrade). Invalidating the token means setting its value to something like @#$reset$#@, and storing it to the DB for an agent with name "A". Next time the agent "A" tries to register, server finds out the token in the DB is willing to be updated with the agent's actual token. And stores it into DB instead of temporary marker "@#$reset$#@".
> 
> There are still some questions to discuss:
> 
> 1) When clicking on the button for purging the existing token, should be the agent disconnected/reconnected or is it ok to continue in this quite undef state?
> 
> 2) Are there any edge cases in this approach? For instance if attacker provides -Drhq.agent.security-token=@#$reset$#@ on purpose (this can be easily handled).
> 
> 3) Possible race condition when registering the different 2 agents with the same name when the token is invalidated for this name.
> ..
> 
> Here is the BZ for it https://bugzilla.redhat.com/show_bug.cgi?id=888016
> 
> JK
> _______________________________________________

I am not sure what usability issue this request is trying to address.
>From a security perspective, it opens the system up for malicious
activity. For example, I could simply have a rouge agent running with no
security token just waiting to take advantage of this feature. By the
time anyone realized it, I have already obtains all the management
credentials for a wide array of targets. I believe there is too much at
risk here from this feature. An administrative user may clear a token
for an agent and then get side-tracked or interrupted during the
process. The result would be that another agent (potentially rouge)
could end up gaining access to the existing inventory and its
configuration (most notably user names and passwords for managed
resources) without the knowledge of the administrator.

Because this deals with security, I think the existing mechanism is
sufficient. The only request I am aware of dealing with "invalidating" a
security token is in the case of a security token becoming compromised.
In such cases, a function should be provided to invalidate the
compromised token and generate a new one. However, the new one would
still be manually copy/pasted to the impacted agent.

The scenario when an agent needs to keep its existing inventory but has
lost its security token or its token has become compromised is not a
common one. Therefore, using the existing mechanism of passing the token
into the agent using the command-line when the agent is started should
be the preferred method. If we still think it is desirable to make this
process easier, then I suggest a command-line argument or agent
operation that can be executed which will cause the agent to ask the
server for a new token. Then, the server indicates the request in the UI
and an administrator can log in and ACK/NAK the request. This forces the
process to be two-way. First, an agent must request the new token on
startup, then, an administrator must acknowledge the request from the
server side.
-- 
Larry O'Leary
https://plus.google.com/u/0/112645929986009801513



More information about the rhq-devel mailing list