Re: [Gnue-dev] Appserver/Common Issues

[Jan Ischebeck]

Hi Stanley,

First, I agree with you in the most points. The only impression I get is that 
we just talk about very high security. I'm not shure how popular NSA Linux, 
or the Linux Security Modules will become in the next years, but I doubt that 
many IT managers of SMBs are using it.
Thats the reason, why I would like that gnue gets a very flexible security 
structure. A structure which let the user choose about using the very secure 
version of GNUe possibly bundled with NSA Linux, or a less secure one with 
some more features :).

Jan


Am Donnerstag, 21. November 2002 15:59 schrieb Stanley A. Klein:
> Jan -
>
> First, let me say that security includes both authentication and access
> control.  The access control consists of providing a "reference monitor"
> that checks each instance (or certain instances) of attempted access
> against the access rules and either allows or denies it.
>
> Authentication is the peocess of determining that the user is authentic,
> i.e., they are who they claim to be.  This is done by receiving information
> (one, two, or three factors -- something the user knows, something the user
> has, and/or something the user is) and comparing the received information
> to a stored version of the information for the authentic user.  The
> "something the user knows" is either a password or an encryption key.
> (Passwords and encryption keys are really the same kind of thing, with
> encryption keys generally being regarded as longer than passwords.)  The
> "something the user has" is some kind of device, probably protected by
> encrypted information.  The "something the user is" is essentially data
> regarding a biometric characteristic of the user, such as a fingerprint or
> eyeball pattern, generally stored in some encryption-protected format.
>
> There are a wide variety of means for attacking authentication systems.
> You identified the issue of capturing the authentication data, such as by a
> sniffer for passwords sent in the clear.
>
> One of the major vulnerabilities in authentication systems is the system
> for determining, storing, and managinng the authentication data.  In an
> encryption system this is known as the "key management" system.
>
> One attack that we can only protect against by procedural means and
> training is the "social engineering" attack.  This consists of tricking a
> legitimate user into revealing a password to a malicious intruder.  For
> example, the intruder might call on the phone and pose as a repair person,
> clsiming that the user must supply a password to allow repairs to be
> completed.  There are many approaches used in social engineering attacks,
> and they often work with untrained and unsuspecting users.
>
> Another classic kind of attack is password guessing.  The simplest version,
> that often works because of poor password selection by users, is to try the
> login name as the password.  A similar version is to try the default
> password, if there is one.  Many users don't change the password from the
> default.  A more complex version applies to  *nix systems where the
> password file is visible to users, although the passwords are encrypted.
> Generally, the encryption algorithm is a system function and the key is
> known, but the encrypted passwords are difficult to break directly.  The
> attack is to run various dictionaries (such as the spellcheck dictionary)
> through the encryption algorithm and look for matches in the password file.
>  This is the reason there are now system administration utilities that
> check proposed passwords and reject them if they are found to be ordinary
> dictionary words.
>
> There is another potential vulnerability in organizations that have
> numerous internal passwords, such as the passwords that might be used for
> remote control devices or among the databases in a multi-tier model that
> are not directly accessed by users.  That vulnerabilty is an attacker
> discovering the pattern, if any, used by the organization in creating and
> managing the passwords.  As with complex user passwords assigned by the
> organization, if they are too hard to remember, users will write them on
> sticky notes attached to the computers.  There are a number of ways an
> intruder can attempt to obtain the password information.  If the
> organization automates the password management process, that automation
> system becomes an object of attack by the intruder.
>
> However, the most serious potential attacks would be those that exploit
> programming errors and other vulnerabiilties to bypass the authentication
> system and gain access to the platform and database without logging in.
> The most frequent kind of attack is based on buffer overflows, but there
> may be other attacks that exploit bugs in Python or wxPython, programming
> errors in GNUe, peculiar features of the database system, or other
> exploitable conditions.  Imagine some kind of bug that allows the attacker
> to provide an input that crashes appserver, not as a denial of service
> attack, but with the aim of getting to a Python traceback and Python
> prompt, or to a system prompt.  Then the attacker can gain a foothold for
> further entry.
>
> Security-relevant operating system code tends to be fairly limited in
> scope, very highly scrutinized, and rapidly fixed if there is an
> exploitable bug.  That may not be true of security-relevant code in
> applications and application infrastructure code that sits above the
> operating system.
>
> Let me give one more example.  I have been monitoring the Linux Loadable
> Security Module discussion list since it started.  One time there was an
> extensive discussion about a design issue that involved a potential
> "time-of-check-to-time-of-use" vulnerability.  IIRC, this is a situation in
> which a legitimate user attempts to access a file, the access is approved
> by the reference monitor, and somehow because of event timing in the system
> an unauthorized access is allowed to occur.  There was extensive discussion
> of the issue.  I don't remember the outcome.  But a number of top security
> experts spent time examining the issue and deciding what to do.  That is
> the level of expertise that is being applied to Linux operating system
> security and to operating system security in general.  I don't think the
> same level of attention is being applied to database or application
> systems.
>
> That's why I think that GNUe should base as much of its security as
> possible on the operating system.
>
> I certainly agree that physical security is important (special rooms, etc.)
> as well as security training for all personnel (so they know not to write
> passwords on sticky notes and to become suspicious of anyone who asks for a
> password on the phone).
>
>
> Stan Klein
>
> At 06:43 AM 11/21/2002 -0500, Jan Ischebeck <address@hidden> wrote:
> >Stanley,
> >
> >I'll comment inline :)
> >
> >Am Donnerstag, 14. November 2002 19:20 schrieb Stanley A. Klein:
> ><snip>
> >
> >> >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.
> >
> >IHMO the main job of the operating system is to provide a secure
>
> environment,
>
> >authentification can be done by the operating system, but it doesn't have
> > to. The security provided by authentification done just in the operating
>
> system is
>
> >not necessarily more secure as when authentification is done by something
> >else.
> >
> >I think authentification consist of two steps:
> >
> >1. getting authentification information
> >2. verify the authentification information
> >
> >The main security risks for 1. are:
> >  a) authentification information is copied ( a keylogger logs the
> > password you've written)
> >  b) fake authentification information is read in (use of water in a
> > plastic bag to trick a finger print scanner)
> >
> >The main security risk for 2. are:
> >  c) the communication is intercepted and a fake "user is authentificated"
> >     message is send back
> >
> >  d) the authentification verifier itself gets modified.
> >
> >
> >All steps should made be equaly high secure.
> >
> >> 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.
> >
> ><sssnippp>
> >
> >> 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.
> >
> >An authentification adapter in appserver do the second step of user
> >authentification: it verifies some user authentification information
> > against some kind of backend.
> >
> >> 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.
> >
> >The difference between a 2-tier and a 3-tier approach in terms of security
>
> is,
>
> >that some of the functions on the local/client side of a 2-tier are moved
> > to a more secure place in the middle.
> >
> >Appserver, as databases too, should run on a server in a special room,
> > which don't allow physical access to the hardware. It should do check the
>
> integrity
>
> >of data provided by a client, and allow a more fine grained access
> >restriction system then a database. It could also be used to bind a client
>
> to
>
> >a fix workflow.  By that it would make the data you have more secure than
> > in a 2-tier approach.
>
> _______________________________________________
> Gnue-dev mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnue-dev

-- 

------------------------
Jan Ischebeck e-Services
address@hidden