Re: [Gnue-dev] Appserver/Common Issues

[Stanley A. Klein]

Jan -

In my view, security in GNUe has to come mainly from the operating system
and database maangement system.  GNUe has to provide features that
facilitate the use of the operating system and database capabilities.  Any
security capability included in GNUe itself must be protected by the
operating system or database and designed so a malicious user (at some
level of sophistication) can not defeat or bypass the capability.

I have interspersed my other comments in your message.


At 06:35 AM 11/8/2002 -0500, Jan Ischebeck <address@hidden> wrote:

>Just some points about appserver and forms and 3- and 2- tier setups.
>
>I. Security:
>
>Requirements
>1. user authentification (not only against a database)

Authentication should best come from the operating system based on
pass-through functions.  Second best is authentication coming from the
database.  Authentication across a network can be done using systems
designed for that purpose that work with the operating system.  

Note that authentication only provides some confidence that the user is who
the user claims to be, or that the message comes from where it purports to
come from.  Can it be falsified or defeated?  Of course, if the attacker
wants to spend enough time and money.

>2. different access rights for different users
>3. different forms/reports/processes(GPD) for different users
>
>The first and second point can be done without many changes in
>forms/reports/common....


The second point is very difficult, and IMHO providing it is a major
challenge.


>To solve the third point there are three posible solutions:
>
>a) add <if user=...> tags to the form file [ IMHO Very BAD ]
>b) download forms from a webserver and let the webserver choose the
>right form definition for the right user [difficult to setup, but needs
>no change to code]
>c) add <if user=> code to navigators process definitions and let
>navigator provide the right form definition for the right user to forms
>[probably the best solution IMHO]
>d) autogenerate forms out of database/appserver metadata [easy
>maintenable]

The third point seems to me to be the easiest to do.  Simply provide
separate gfd and gpd files to the various users, protected by the operating
system access control capabilities.  Having a feature in Navigator that
provides a menu item greyed out with no functionality behind it might help
provide Navigator screens that seem to be the same (for training purposes)
but block certain functions that the particular user is not allowed to access.

Another feature that might help in maintaining gpd, gfd, and grd files that
are separate for separate users would be an "include" capability in the
gfd, gpd, and grd processors.  That way the individual gfd and gpd files
could simply consist of include statements pointing to the files containing
the portions of the definition the user is allowed to access.

BTW, if this can be done without being vulnerable to bypassing, it is
probably the easiest way to get a version of Role Based Access Control.  By
bypassing I mean such schemes as a malicious user managing to get some
tampered GNUe code and configuration files into their home directory and
redirecting Python to use the local versions rather than the system
versions.  

The easiest way to prevent bypassing is "capturing" the user, for example
by sending the user from system login right into a manu system from which
they can't escape.  This would require steps such as handling all possible
exceptions (that would otherwise crash to a Python traceback or system
prompt) within the system, preventing the user from booting into anything
other than the installed system, and preventing the user from accessing any
of the usual operating system tools (like file copying).  This would be a
good approach for something like a point-of-sale terminal.


>
>II. Appserver vs. Common
>
>I think we need a delegates/plugin architecture for common. I think so
>because IMHO we need a common which can be very powerfull and very lean
>at the same time. The "I prefer 2-tier" gnue developers need
>authentification adapters, possibly they want to access business objects
>too. But they don't want to add another layer, don't want to use 3-tier.
>Ok, no problem. Just make these extra functionality be plugable into
>common dbabstraction, or even moved from appserver to common.


Perhaps I don't understand the new appserver and 3-tier architecture well
enough to be able to comment on this.  I don't know what is meant by an
"authentication adapter," but refer to my remarks above on authentication.
For a while I seemed to get the impression that the new 3-tier appserver
interface would look more like the 2-tier interface than the old appserver
interface did.  Now, I think my impression may be incorrect.

>From a security viewpoint, the difficulty with the old appserver (and the
reason I think access control may be a major challenge) is that the mapping
of data items from the user side of appserver to the database side seems to
be complex, implying that appserver has to do some of its own access
control.  Unless those access control functions can be pass-throughs from
the operating system or can be isolated in files that can be well protected
by the operating system, the appserver is likely to be much more vulnerable
to attack than the 2-tier approach.


Stan Klein