Re: [Gnue-dev] New Architecture Drawing based on Whitepaper.

[Stanley A. Klein]

At 06:49 AM 1/23/2003 -0500, Leandro Faria Corsetti Dutra
<address@hidden> wrote:

>On Fri, 2003-01-17 at 15:27, Stanley A. Klein wrote:=20
>>=20
>> Let me explain the importance of the mapping to assurance.  First,
>> assurance is important if the quality of enforcement of rules in the
>> application is ever likely to need to be justified to a hard-nosed audito=
>r,
>> a worried Board of Directors, a regulatory body, a judge, or a security
>> accreditation board (used in some government agencies).
>>=20
>> GNUe itself is not likely to be able to provide the quality of enforcemen=
>t
>> (i.e., the assurance) those people are likely to be looking for.  In thos=
>e
>> cases, the user will need to be able to depend on the operating system
>> and/or the database system to provide suitable enforcement. =20
>
>       As I see it, rules must be enforced by the DBMS, the OS would never be
>enough.  Unfortunately, there are rules that only would reasonably be
>implemented in a RDBMS, of which the only available implementation is
>proprietary, namely Alphora Dataphor.  One is left with a choice of
>either implementing a true RDBMS, or instead use the least bad
>approximation, which currently seems to be SQL.
>
>       As for OO, it can't provide in itself a data model, integrity
>constrainst and interactive manipulation, not even to the already low
>SQL standards.  OO sure is nice to programmers, but not to end users and
>DBAs.  And anyway one can do OO on a relational database nicely enough,
>even if on SQL it is more of a chore.


First, I want to say that all security flows from the operating system.
Even the DBMS depends on the operating system to assure the protection of
its security functions.

Second, let me say that it may be possible, depending on the details of how
the DBMS is implemented, to use the operating system to enforce rules
without depending on the DBMS.  For example, if an RDBMS places each table
in a separate file, places the tables of a database in a separate
directory, and can be configured to use the user's permissions as the
access controls for the database files, then the operating system can
enforce certain kinds of rules.  Also, it may be possible to place
operating system access controls on some of the GNUe configuration and
definition files to enforce certain kinds of rules.

However, all that having been said, I think the ability to enforce rules
has a very sensitive dependence on the details of the rules themselves.
For example, a rule that looks at fields within a record, combined with
user permissions, to allow or disallow operations on other fields could
only be implemented by a very sophisticated DBMS or an application program
outside the DBMS that would have a lower assurance level than either the
operating system or the DBMS.  

What I'm thinking about in this example is the kind of rule that says any
member of a certain class of users can be either an originator or an
approver of a certain kind of transaction, but the originator of a
transaction must get someone else to approve it.  This is the same as
saying that there are two roles involved in the transaction but any two
people (in the relevant class of users) can fill either role.  It is
difficult to identify an operating system and DBMS that will enforce such a
rule for a GNUe configuration with the same level of assurance as a rule
that clearly creates a class of originators and a class of approvers, and
does not allow an originator to approve or an approver to originate.  The
situation becomes even more difficult if the rule states that the approval
process changes if the value of the transaction exceeds a particular
threshold.  I'm sure there are other very common kinds of business rules
that could easily make it difficult to achieve more than minimal assurance
that the rule is being enforced.  

The bottom line to all of this may be that even if a business rule is
clear, complexity makes it difficult to assure that it will be enforced,
i.e., that someone will not be able to bypass or otherwise subvert it.  And
details are very important.


Stan Klein