Purging the agent's security token

Jiri Kremser jkremser at redhat.com
Tue Dec 18 15:33:05 UTC 2012


> We'd have to test the behavior of the system if the token is changed while the agent is connected. I *think* we check the token on ?> every message we get from the (not sure about this) - if this is true, the agent will probably be stuck receiving "unauthenticated" > errors until it switches to another server or it is restarted.

I was trying it yesterday and it worked, I've tried the "get live button" on the monitoring tab and there were no errors in the log event the token was invalidated. I guess, it depends on the type of the communication between agent and server, I mean availability report needs authentication for example.


2)
you are right Mazz, I just wanted to be sure about it.

3) Jay:
It may happen theoretically in the CoreServerServiceImpl.registerAgent() method. If two different agents with the same name pass all the "iffs" and try to create new DB record by calling agentManager.createAgent(agentByName). But I guess, there is a constraint on the Agent table requiring the unique name, so Hibernate should protect it. 


----- Original Message -----
From: "John Mazzitelli" <mazz at redhat.com>
To: rhq-devel at lists.fedorahosted.org
Sent: Tuesday, December 18, 2012 3:15:13 PM
Subject: Re: Purging the agent's security token

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

We'd have to test the behavior of the system if the token is changed while the agent is connected. I *think* we check the token on every message we get from the (not sure about this) - if this is true, the agent will probably be stuck receiving "unauthenticated" errors until it switches to another server or it is restarted.

I think it would be best that the user be told to shutdown the agent, unless the agent can self-correct in this situation.

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

It should be irrelevent if the agent's token is that special token - that is only meaningful if coming from database. In other words, if the agent sends us @reset@, it will fail to authenticate if the token in the DB is a real token (so that's good). It will potentially pass authentication if the token in the DB is @reset@ - but 1) by the very nature of the case, the user wants the agent to pass by the fact the user reset the token and 2) the server code shouldn't get that far - once it sees @reset@, it will have to generate a new token and send it back to the agent.

So, I don't see how someone setting the token on the agent to that @reset@ token would help circumvent security. Unless I'm missing something.

> 3) Possible race condition when registering the different 2 agents
> with the same name when the token is invalidated for this name.

don't know.
_______________________________________________
rhq-devel mailing list
rhq-devel at lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel


More information about the rhq-devel mailing list