db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dag.Wan...@Sun.COM (Dag H. Wanvik)
Subject Re: no protection of db boot - intended?
Date Wed, 28 Feb 2007 21:25:32 GMT

Hi Dan,

Daniel John Debrunner <djd@apache.org> 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

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


View raw message