| Subject | Re: [Firebird-Architect] External engines - security |
|---|---|
| Author | Alex Peshkov |
| Post date | 2007-10-22T10:42:13Z |
On Monday 22 October 2007 14:38, Adriano dos Santos Fernandes wrote:
yes, that's why calling later Java 'safe' language.
Discussion about security of external engines happened to move into Java-only
direction. But initially we were going to provide access to definitely
insecure languages, like Delphi. I'm not sure, have we found acceptable
solution, or not. I see 2 main approaches:
1. Deal with it exactly like we do with UDFs (which certainly can send spam
and provide other undesired activity if written that way). But due to limited
access to them this it is not a security problem now.
2. Invent an approach, making it possible to safely store Delphi modules (also
UDF - what's a difference?) directly in a database and use them.
Looks like the only use in storing unsafe modules in a database is an ability
to store them in a same form as safe one (PSQL, Java). But in all the rest
aspects we have more disadvantages then advantages. If we already store some
modules in a special directory of filesystem any database owner can easily
use them in his database. That's false for per-database stored modules - to
use them one need to contact SYSDBA. To store own modules on a disk one need
to contact server admin, but is it much harder compared with contacting
SYSDBA?
Therefore I suggest not to re-envent the wheel, trying to replace FS security
with our own. We must say, that we have safe languages (currently PSQL and
Java), that are free to be used by anyone with appropriate access to
database. We keep (for backwards compatibility) UDFs, we may even add unsafe
(Delphi, C++) general modules if we really need one. But they will follow the
same rules as UDF.
> Jim Starkey escreveu:Roman, can we provide safe configuration to be used with firebird? I suppose
> > No, what is this whole line of discussion about? What are you trying to
> > achieve with the JVM?
> >
> > A major consideration is what JVM. Firebird doesn't have one. Most
> > open source JVM are GPL, so you can't modify one. That pretty much
> > means you're going to have to take one off the shelf and load it
> > dynamically, so creating a new security model is out of the question.
>
> Creating a security model for Java code is possible extending class
> library, but as Roman said, this may be risk due to complexity of Java
> security model.
yes, that's why calling later Java 'safe' language.
Discussion about security of external engines happened to move into Java-only
direction. But initially we were going to provide access to definitely
insecure languages, like Delphi. I'm not sure, have we found acceptable
solution, or not. I see 2 main approaches:
1. Deal with it exactly like we do with UDFs (which certainly can send spam
and provide other undesired activity if written that way). But due to limited
access to them this it is not a security problem now.
2. Invent an approach, making it possible to safely store Delphi modules (also
UDF - what's a difference?) directly in a database and use them.
Looks like the only use in storing unsafe modules in a database is an ability
to store them in a same form as safe one (PSQL, Java). But in all the rest
aspects we have more disadvantages then advantages. If we already store some
modules in a special directory of filesystem any database owner can easily
use them in his database. That's false for per-database stored modules - to
use them one need to contact SYSDBA. To store own modules on a disk one need
to contact server admin, but is it much harder compared with contacting
SYSDBA?
Therefore I suggest not to re-envent the wheel, trying to replace FS security
with our own. We must say, that we have safe languages (currently PSQL and
Java), that are free to be used by anyone with appropriate access to
database. We keep (for backwards compatibility) UDFs, we may even add unsafe
(Delphi, C++) general modules if we really need one. But they will follow the
same rules as UDF.