Hi Jim,
If the on disk database is encrypted, and the end user is only provided
enough credential keys to see what the application developer wants them to
see, then, the information remains secure.
The assumption on my part is that some elements of the database such as the
DDL descriptions, source and other elements are NOT for end user
consumption. There is no reason for a end user to have the keys to
decrypt that information.
BUT, from a developers standpoint, once they say that that information is
to be encrypted and invisible to the end user, they do not have to
continuously worry about deleting source code or their comments. They
don't have to alter their deployment scripts and if they are not sure what
version the end user has, they can use a custom embedded engine tool to
connect directly to the database to review the actual database comments and
source to confirm that the appropriate patches have been applied.
What it does mean, is that if someone tries to connect to a database that
is fully encrypted and their client does not securely pass the decryption
key to the server, the server will just come back with an error about the
database being corrupt or some other agreed upon error message.
On 4 September 2014 11:04, Jim Starkey <j...@jimstarkey.net> wrote:
> 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>
> 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
>
>
------------------------------------------------------------------------------
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
