Dalton, it's theoretically impossible to hide something with system
privileges and without encryption on an open source product. All that's
necessary is for someone to compile a version without checks. Now, it
is true that we're only trying to protect the "source" from people too
ignorant or lazy to decompile the BLR, but these people probably aren't
too ignorant or lazy to download a security crippled version of the product.
We are, in short, between a marshmallow and a soft place.
On 9/4/2014 10:49 AM, Dalton Calford wrote:
I still argue that we should take the opportunity to not only fix this
issue, but to improve the FB product functionality.
The core requirement is to stop non-authorized users from viewing
source code. The current process is to delete the source code from
the database.
There is also the common work around of inserting SYSDBA into the
roles table to prevent sysdba from connecting to the database. This
functionality is also being removed by locking off the system tables.
FB 3 is already working on stronger user authentication methods -
sysdba in newer versions of firebird does not necessarily mean the
same as it did in earlier releases.
On disk and over the wire encryption are also being worked on if not
implemented.
So, a database can theoretically have some items that are encrypted on
the database owners security authorization that even SYSDBA can not
see, nor can they decrypt since the on disk records are encrypted
using the database owners encryption key vs the regular users
encryption key.
So, DDL statements such as GRANT VIEW which is used by MS SQL for
metadata security could be applied to FB.
This would not only answer the current problems of hiding the source
code, it would still allow authorized developers to check the source
for version comparisons.
It would also provide functionality which is provided by other
database engines and which would simplify the DBA's job.
*
GRANT VIEW DEFINITION TO public [WITH DECRYPTION KEY privatekey];
REVOKE VIEW DEFINITION TO public [WITH ENCRYPTION KEY privatekey];
This statement will override metadata-visibility limitations at
the database level. All metadata in the database will be
visible/invisible to *public (or whoever you define)*.
*
GRANT VIEW DEFINITION ON OBJECT :: <object_name> TO public [WITH
DECRYPTION KEY privatekey];
REVOKE VIEW DEFINITION ON OBJECT :: <object_name> TO public [WITH
ENCRYPTION KEY privatekey];
This statement will override metadata-visibility limitations at
the object level. All metadata for the object will be
visible/invisible to *public*. If the object is a table, all the
columns, indexes, statistics, and constraints of the table will be
visible to the *public*. This behaviour also applies to GRANT VIEW
DEFINITION ON ASSEMBLY and other similar GRANT statements.
Obviously the encryption/decryption part would wait for later versions
of FB so as to not hold up on the release, but, for now, the behaviour
could be implemented. I believe such functionality for hiding
columns/tables is available in the redsoft version of firebird.
The extension to the parser could be provided now, while the hiding of
an objects source would delete the source until the encryption process
is properly thought through.
On 3 September 2014 07:44, Carlos H. Cantu <lis...@warmboot.com.br
<mailto:lis...@warmboot.com.br>> wrote:
I think we already reached a point where core developers can hit the
hammer in what will be the chosen "solution" of this problem in FB 3.
I would be satisfied with either relaxing rules in
rdb$triggers/procedures, or with new syntax, or with last Jim's
proposal of SET statement. I'll leave this to you (core developers)
decide what one is more adequate for the time being.
Another option (maybe not so simple) could be a flag in the database
header that would tell Firebird if the source should be kept or not.
The flag could be set with gfix, as we already do with forced writes,
etc.
About the other proposals, they can be discussed again for future
releases, after FB 3 is finally out.
[]s
Carlos
http://www.firebirdnews.org
FireBase - http://www.FireBase.com.br
------------------------------------------------------------------------------
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
------------------------------------------------------------------------------
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
------------------------------------------------------------------------------
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
