Tutorial 2008-02: System Security

System Security such as Authentication and Encryption is available and fully supported in the Querix 4GL envrionment. However, the implementation and configuration, in particular for Unix, can be rather tricky and requires knowledge of the chosen operating system's security environment. You will find bellow information which will be useful for anyone deploying a security shell arround the 4GL Application and graphical clients.

Authentication

Windows

On Microsoft Windows, the application server uses the standard Windows API allowing users that are local to the server as well as domain users to authenticate to the ‘Hydra4GL’ application. Once the user has been successfully authenticated, the application server will load the authenticated user’s security context, registry hive and environment and launch the process as the authenticated user.

Unix/Linux

Because of the many different methods that are used for authentication under UNIX operating systems, we currently offer three authentication modules for UNIX operating systems; a crypt based authentication module (Crypt), an MD5/shadow based module (Shadow) and a PAM module. During the installation process you will be asked by the installer to select which module you wish to use on the server that you are installing to. The following descriptions may help you to decide which method is suitable:

Crypt:

This is the simplest authentication method that is available for UNIX based operating systems. On a system where the crypt method of authentication is used, all user information including the password is stored in the /etc/passwd file. The passwords are encoded with the following one-way hash:

• user sets a password
• Password is encoded with randomly generated value called a salt
• The salt is then stored along with the encoded password in the /etc/passwd file

This method means that any particular password could be stored in 4096 possible ways. When a user logs into the system, the salt is retrieved from the /etc/passwd file. This salt is then used to encode the supplied password and this encoded password is compared with the stored encoded password in the /etc/passwd file; if there is a match then the user is authenticated.

Due to the fact that the /etc/passwd file must remain world readable, it means that anyone who has access to the system can have access to everyone’s salt / password combination and using the list of salt values could perform a very simple dictionary attack (whereby a large list of standard passwords are encoded using the salt values gained from the passwd file, searching for matches with the encoded passwords in the passwd file) to gain access to other accounts including system / root accounts.

Shadow:

To get around the problem of a user being able to gain access to the salt / password combination from /etc/passwd file the password shadowing method was introduced. This gets around the problem of relocating the passwords to another file (usually /etc/shadow) that is only readable by the root user, replacing the salt / password combination with a character (this is usually 'x'). This effectively removes the ability for a user to perform a dictionary based attack from the encoded passwords on the system. 

Pluggable Authentication Modules (PAM)

The third type of authentication method we offer for UNIX is a PAM based module. PAM allows a systems administrator to decide which of the underlying operating system authentication methods an application should use rather than this information being hard coded into the application itself. This is accomplished by means of a collection of libraries and APIs that the application can use to request authentication information. PAM also provides the ability to use many different methods of authentication (e.g. smart cards) by means of modules that 'plug into' the PAM library to perform the actual authentication and pass the results back to the PAM library.

The systems administrator can then configure separate applications to use different methods of authentication and PAM modules by means of the PAM configuration files. When a PAM application is launched, the PAM library will read the configuration for the application and act appropriately based on the information contained within the PAM configuration files. PAM also allows the stacking of authentication modules so that if one method of authentication fails for a user a secondary method can be attempted before failing.

There are two ways that PAM can normally be configured: using a single file located at /etc/pam.conf or using a collection of configuration files located within the /etc/pam.d directory. It is worth noting that if both /etc/pam.conf and a /etc/pam.d/sytle configuration are present on the system, PAM will use the /etc/pam.d/ rather than the /etc/pam.conf for its configuration.

The /etc/pam.conf file is made up of a list of rules, each placed on a single line. The format for each line is of the following format:

service type control module-path module-arguments

The syntax of files contained within the /etc/pam.d/ directory is identical apart from the absence of the 'service' field; in this case the service is the name of the file in the /etc/pam.d/ directory.

The service is the familiar name of the application (e.g. 'qxinetd2'). The service name other is generally reserved for giving default rules for services that aren't defined.

The type field defines the management group that the service belongs to and can be set to account (non-authentication based account management), auth (user authentication & group authentication), password (application can update user password) or session (this is used for operations that need to be either before or after a user has authenticated).

The control field configures what the PAM library should do if the user fails to authenticate and can be set to required (this will return failure after all methods have been completed on fail), requisite (like required, but if this module fails control is passed directly back to the application without processing any additional modules), sufficient (success of this module is enough to satisfy the authentication requirements of the stack of modules [note this is ignored if a prior module had the required flag]) or optional (the success or failure of this module is only important if it is the only module in the stack associated with the service & type).

The module-path is either the full path of the PAM-module that is to be used by the application, or a relative path from the default module location (normally /lib/security).

Finally the module-arguments are a space delimited list of tokens that are passed to the PAM module as arguments.

Getting PAM to work with your applications

When the ‘Hydra4GL’ application server is running in PAM authenticating mode, it will identify itself with the service name of 'qxinetd2'. With this in mind, if you wanted to configure PAM so that the application server could use PAM, you could add the following lines to the /etc/pam.conf file:

qxinetd2   auth sufficient   libpam_krb5.so.1

qxinetd2   auth required     libpam_unix.1 try_first_pass

This states that the authentication details provided by the application server should first try the kerebos PAM module and if this succeeds then the user has been authenticated. If this fails, the system should use the same password and attempt to use the UNIX PAM module for authentication. If the UNIX module fails, then the PAM system should return authentication failure to the qxinetd2 service (the 4GL application server). If the system is configured to use the /etc/pam.d/ directory configuration rather than the /etc/pam.conf file, then the systems administrator should create a /etc/pam.d/qxinetd2 file containing the following:

auth sufficient   libpam_krb5.so.1

auth required     libpam_unix.1 try_first_pass

This will attempt to perform the steps in the /etc/pam.conf example stated above.