Let's try another tack on this problem. What is the best possible way to
solve it if schedule were not a problem? And is this a special case of a
more general problem?
Here's an idea to get the creative juices working: Suppose the database
parameter block were extended with a composite containing quadruples of
<schema, table, field, key>, and if given, instances of the given field
would be encrypted and/or descripted with the given key. This would be
robust, defensible security for any field and would be easy to implement in
both database tools and the database engine, and would have no impact on
system tables, the API, or transmission layers. Carlos would be happy, the
hard-security guys would be happy, and the mechanism would generalize to
user as well as system tables.
This is a starter solution. There must be many more lurking out there.
On Sunday, August 31, 2014, Dmitry Yemanov <firebi...@yandex.ru> wrote:
> 31.08.2014 15:51, Carlos H. Cantu wrote:
> >
> > We have a "hack" that many people uses for a long time, to make it
> > more difficult to stole procedures/triggers source (more difficult,
> > not impossible, since BLR can be decoded to source). They know it is
> > not 100% safe, but so far it is the only way to avoid
> > "standard/common" users (the ones who knows only how to connect to
> > database and run select), to have access to the sources.
>
> What about unencrypted distributed databases? Should we care about
> hiding PSQL source also from SYSDBA / DBO? Are there real cases when it
> would be needed?
>
> > 1) Create an official way to make the source null
> > 2) Create a way to obfuscate the source
> > 3) Create a way to store the source encrypted
> > 4) Leave the rdb$procedures and rdb$triggers writable (or at list the
> > source field).
> > 5) Create special privilege for users to be able to retrieve the
> > source code.
>
> See my question above. I would hate to support an object-level privilege
> that can be revoked from the object owner. And, given how our security
> works now, it won't work for SYSDBA anyway.
>
> > 1, 4 and 5 seems to be the only solutions that could be done without
> > delaying FB 3 release (core developers can confirm this).
>
> So far I tend voting for (1), using a special syntax.
>
>
> Dmitry
>
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds. Stuff that matters.
> http://tv.slashdot.org/
> Firebird-Devel mailing list, web interface at
> https://lists.sourceforge.net/lists/listinfo/firebird-devel
>
--
Jim Starkey
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
