|
Hi Brian, Good observations. Condor has a protocol for invalidating security sessions. It is simple: when the receiver does not recognize a security session, it sends a message back saying so, which causes the sender to promptly drop the session from its cache. It is not secure. Somebody snooping network traffic could observe the security session ids that are being used and send messages back to cause them to be dropped from the cache, which will create extra work in Condor due to the need to start from scratch next time. If they can snoop the network, there may be other annoying things they can do that degrade performance as well. Not sure if there's much to be done about that. There is one important point that you bring up. Condor only invalidates security sessions when it does not recognize them. If it recognizes them but they are not authorized to do what they try to do, it does not invalidate them. Perhaps it should. And perhaps there should be a way to clear the cache without restarting. I see this tantalizing bit in the code: void DaemonCore :: invalidateSessionCache() { /* for now, never invalidate the session cache */ return; if (sec_man) { sec_man->invalidateAllCache(); } } --Dan On 12/6/10 10:28 AM, Brian Bockelman wrote: Hi, I've noticed that condor_reconfig and security settings interact very poorly. In the latest Condor, my best recommendation is: if you change security settings, never do "condor_reconfig" or "condor_restart" - restart with "service condor restart". It's frustrating to not be able to use restart/reconfig. Basically, when you change settings such that previous security session is no longer valid (my example is when we switched from IP based security to GSI based security), the security sessions continues to be used. In my case, the condor_master was no longer able to speak to condor_schedd because the condor_master kept using the same (valid, but no longer authorized) security session. I would argue that security sessions need to be reset when condor_reconfig is done (or if Condor is smart enough to only do it when security sessions have changed, that's fine too). So, in my case, the condor_schedd would tell the master its session should be invalidated. This would solve the issue at hand, but there are some things to think about: 1) condor_reconfig can be triggered with only WRITE access; someone with WRITE access could trigger arbitrary reconfig and have an impact on security sessions. This starts to sound like the basis of a "TCP RST"-like attack. 2) Can we securely invalidate sessions? I don't know this, but it feels like there would be some difficult issues here. Brian_______________________________________________ Condor-devel mailing list Condor-devel@xxxxxxxxxxx https://lists.cs.wisc.edu/mailman/listinfo/condor-devel |