Steve Tendon <steve@...> wrote:

>May I ask you - really all of you here on IB-Architect - to suggest a
>solution. Can we please stop focusing on what we CAN NOT do, and instead
>come up with ideas of what we CAN do.

The first step is to make requirements clear before considering solutions,
and to stop thinking that cryptography is a solution to any security
problem. After that, I think it might be worth considering what we can do.

>Or is it really so that there is no solution to these problems? If there is
>no technical solution, then lets give up and hand the ball over to AnnH and
>PaulB, and ask: how do we deal with the perceived deficiency (i.e.

perceived

>by end-users in the sense of feature-matrix comparison vs. other products)?

On requirement 2, securing an end-user's data:

I don't see that the requirement needs an architectural solution. We agree
that the requirement can be met using current mechanisms. I am certainly
not saying that Interbase's default "security" is in any way adequate, but
the current major problems are not architectural, but in implementation and
installation.

An abbreviated list of what I believe needs to be done: On NT an Interbase
server should run under an non-privileged account, and all the databases
should be ACLd to only be readable by that account. On Unix systems it
should run as a non-root user in a chrooted gaol, again with correct
permissions. The database paths should be administrator configured on the
server and not accepted from clients. The local protocol should be ignored
(or removed) until it is fixed. For single user applications, the server
should be able to run in an application process context, and therefore be
the restrictions of the user's account. The server should only listen for
connections on administrator specified ports and interfaces, with specified
rules for acceptable connections. isc4.gdb should die. &c.

You can configure an Interbase server to close the most obvious holes in an
installation; it has been discussed on this and other lists. Developers
just need to apply their brains, and fix their installation procedures.
Today, as always, an application developer must provide instructions for
installing a piece of software securely. It is no one else's
responsibility. If the developer can't do that, they deserve everything
they get, and helping them to attempt to pull the wool over everyone's eyes
doesn't do anyone any good.

All this applies to superserver, of course. Classic should just be taken
into the woods and shot.

On requirement 1, hiding your schema from competing developers:

Technically, I cannot see how the problem can be solved without also
requiring the use of tamperproof and sealed hardware. Generalising a
solution also conflicts with the whole Open Source philosophy: Such a
facility depends on obscurity, and enforced release of the source code
serves to remove obscurity around an implementation. To meet this
requirement almost implies that each developer must develop his own
mechanism for obscuring that which he wants to keep secret, and never
release the source.

It is also important to remember who the attacker will be: A competent
developer. If a developer wants to know what your schema looks like, he
can. My view is that developers should stop feeling insecure and get on
with some real work.


Jan Mikkelsen.