Hi Dan, Daniel John Debrunner <[EMAIL PROTECTED]> writes:
> 1) If a boot with failed authentication shuts the database down, then > at least it has to ensure that no valid user has connected to it since > it was booted. Yes, I thought of that.. but think I'll have to handle that as part of policing encryption boot anyway (DERBY-2264): Is there a (simple) way to block other connections while doing a boot, credentials check and then shutdown/reboot with encryption? One would want to make this atomic.. > > 2) Having such a request shutdown the database might actually increase > the potential of a denial of service attack. More work would be > performed for an invalid request, thus consuming more cpu time on the > machine. I agree. But unauthorized boots may interfere with dba activity; if a dba does a shutdown to prepare for an encryption reboot, that reboot might not be performed as attempted if the database was rebooted by someone else (by somebody unauthorized or not) in the meantime. This is compounded by the fact that if db is already booted, it seems that boot parameters are silently ignored, is that by design or accident? Not exactly a denial-of-service attack, perhaps, not sure how serious this is, but it seems a hole to me. But fixing this might open the kind of DoS hole you are pointing to, not sure which hole is more serious. Maybe one could keep a cache in the engine of (already) failed login credentials to alleviate that (except when external authentication is used, of course)? > > 3) Which "end-user" do you mean above? A remote user can't tell that > the database was booted or not so it's not surprising to them. :-) I thought of a dba, sorry for my lack of precision. Dag
