I don't necessarily disagree with you, but what you suggest requires
major design, buy in, and implementation, none of which are remotely
possible in the available time.
Encryption is all about key management which is not simple and if isn't
correctly designed and implemented, is useless. It also requires
encrypted links to pass keys, which is another issue.
Given the amount of discussion required to decide that Carlos has a
problem worth addressing, the idea of an encryption infrastructure could
be resolved in a few days is hopeless given that even after a decade or
two, even SSL is riddled with problems.
On 9/4/2014 11:17 AM, Dalton Calford wrote:
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
<mailto: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 <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
athttps://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
