Hello Pri,

> In my case, filesystem level permission is not applicable.

Do you mean that it will (also) be installed on filesystems that don't
have access protection (like FAT) ?

If so, anybody with access to the filesystem can grab the database,
take it home and examine it. You can encrypt the data, but since
that's done by an application on the same computer (if you use
Embedded), malicious users could also copy the application and
decompile it.

Metadata can't be encrypted, except that you can delete the PSQL
source of your stored procedures and triggers (not that it will help
you a lot - see the meta security article that Adam referred you to).

Also ask yourself - if you encrypt the data on an unprotected
filesystem, how are you going to protect the key? It's very very hard
to protect anything if you work on a filesystem where you can't shield
data from unauthorized access.

> If the database is shared between few computers (and means that all
> of them must have read/write permission),

If the database must be accessed from other computers than the one it
lives on, you can't use Embedded. The database must always be on the
same computer (physically! no network paths) as the server, whether
it's an embedded or a regular server.

Another consideration is that an embedded server places an exclusive
lock on the database, so you can't have simultaneous connections.

I think you could solve at least part of your problems by opting for a
regular client-server model after all. With a regular Firebird server:

- You can place the server and the database on a computer that only a
few trusted people (administrators) have access to; or at least on a
protected filesystem, in a tree only accessible by those few.
You can even place them on an encrypted filesystem.

- You can decide who gets access to the database at all, and you can
manage access rights to any objects inside the database. "Access"
meaning here that users can query the server for data, *not* that
they can get to the file itself.

- Users can connect from across the network, but they must provide a
valid username with the right password. Once authenticated, they
only have access to the parts you want them to have access to, and
they have the type of access that you determined (e.g. read-only,
read-write, execute, etc.)

- Several users can connect simultaneously.

You can protect your data and database structure even more by
introducing a middle layer: clients connect to the middleware, and the
middleware connects to the Firebird server. This Firebird server could
even be an embedded server (not that this would be my choice) provided
that it and the database are hosted on a computer/filesystem that your
ordinary users have no access to.


Installing a regular Firebird server is a bit more work than packing
Embedded with your application, but not that much. It's a pretty
simple and straightforward process, and you can make it part of the
installation procedure of your application.

If you *really* won't do that, you must accept the low or totally
absent security that's inherent with users having access to the
database file itself.

Or, look at it this way: why go out of your way to think up all kinds
of protection/encryption schemes for an inherently insecure access
model, if you can achieve the same level of protection by using a
proper client/server setup, which is certainly less work?


Greetings,
Paul Vinkenoog