Leyne, Sean wrote:

>>In addition, a security manager could reasonably expected to get
>>
>>
>involved
>
>
>>in
>>
>> 1. File open, so a database could be kept on a password protected
>>
>>
>or
>
>
>> encrypted volume
>> 2. Physical read and writes, so physical data can be encrypted at
>>
>>
>the
>
>
>> page level
>> 3. TCP connections, to enable use of SSL between the client and
>>
>>
>server
>
>Personally, I think that this is too broad a definition. These are
>separate problems.
>

Definitely worth discussing. Yes, authentication and file level
encryption are separable aspects of security. There are certainly more,
such as finer control over table access rights. Databases have been
operating for quite some time with a security model completely
inadequite for their intended use. For example, the vast majority of
existing applications have a single login account, but in fact are
operating as an agent of clients. Right now the host program has to
manage access control. A much more intelligent way to handle the
problem is to let the application program control security policy on a
database connection, letting the database system enforce this security.
By the time you've broken out a full half dozen areas of security
policy, each with a separate loadable plugin, you're going to wish you
had a single extensible architecture.

A variant of the Vulcan provider architecture would work very nicely.
The plugin API is structured around an architecturally controlled
SecurityProvider class, the implementation of which is all no-ops.
Security providers inherit from the class, and export an instance of
their class. This is infinitely extensible and backwards compatible at
both the source and binary levels.

An nice embellishment would be to allow a chained sequence of security
providers. The implementation is dirty simple. The base class
implementation passes the call along if its chained, otherwise does an
appropriate no-op. This would allow a single controlled interface to
accomodate a sequence of security providers, one performance
authentication, another file level encryptions, maybe a third
implementing a more rational table access control policy.

But the essential idea is that a security provider provides
comprehensive security policy. If one wants to solve less than the
world's accumulated security problems, that's OK. He just ignores the
methods he doesn't want to implement.

>Database encryption has little to do with the user authentication
>method, the same is true for the method by which the server/client
>choose to communicate.
>
>The scope of the problem should be broken up into the separate elements,
>which you've outlined, each with its own API definition.
>

How the client side security plugin packages authentication data into
the database parameter block has everything in the world to do with
whether the connection is using SSL or not. Sending passwords is OK
with SSL but very much a no-no on a potentially tapped line.

Security is a matrix, not a set of points. The pieces have to fit
together. Attempting to break a policy into a series of unrelated
elements is very difficult, maybe impossible, to implement.

>>The Vulcan configuration file systems makes it easy to design the
>>mechanism for specification of and parameters for security managers on
>>
>>
>a per-database basis, so all sorts of specialized schemes are possible
>
>
>and probably even desirable.
>
>
>
>I read to mean that it will be necessary for the SYSDBA to define a
>configuration file for each database on the server, correct?
>
>

Not at all. Vulcan configuration files are chained so policy can be
established and enforced at various levels, but there is no reason to
split things into per-database configuration files.

In the default case, the DBA doesn't have to do any at all. The product
is distributed with canned "catch all" configuration files that does
exactly what FB1.5 does. If the system manager is happy with this, he
can leave well enough alone. If he wants to change the policy for all
databases, he has a single point of control. If he, or users or
departmental managers, want finer control, they can play with the
files. The object name wildcarding give him (or them) loose or fine
control. They can, for example, establish policy for all databases
falling within a given directory tree. What they do with it depends on
their requirements.

>Isn't it more appropriate to think of the user and encryption security
>settings as something which is stored within the database (in the header
>page, so that the settings are "hard-wired" for the database?
>
>

Why would you want to hardware a single implementation? Hasn't history
demonstrated that the one-size-fits-all only works for things made out
of Spandex?

Besides, how an encrypted database read itelf to find its decryption
data? Answer: it can't. Storing the database encryption key, itself
encrypted, as a attribute for the security provider object definition
works. Storing the encryption key on an encrypted header page doesn't
quite work.

>The question of the SSL or client/server transport security would be a
>setting of the server, why would it vary by database? I can't think of
>any network admin allowing for mixed communication modes over a network
>interface.
>
>
>

Come, Sean. Surely you will concede that the security requirements for
credit card validation are different from managing the office football
pool. Credit card stuff is just money; we're talking football here.


[Non-text portions of this message have been removed]