Application Level Security

QM includes an internal security system that imposes restrictions such that a user can only access QM if their user name is registered using the CREATE.USER or ADMIN.USER command. Users who are system administrators within the underlying operating system are not restricted. When installing a new QM system, the installer will ask whether the security system is to be enabled. This choice may be amended later using the SECURITY command.

On systems running Windows 98/ME, the underlying operating system does not have adequate user authentication. If security is enabled, users entering QM over a direct network connection will be required to enter a valid username and password that is private to the QM environment and is created using the CREATE.USER or ADMIN.USER commands. If security is not enabled, network users can connect directly to QM with no authentication. Entry to QM from the operating system command prompt or by use of the QMConsole menu item is unrestricted.

On later versions of Windows and on other platforms, users entering QM directly from a network will always be required to enter a valid username and password known to the operating system. Furthermore, if security is enabled, this username must also be in QM's own register of usernames. If there is no entry in the user register for the user, the system looks for an entry for DEFAULT (case sensitive) and, if found, uses this to define the user's rights. Entry to QM from the operating system command prompt (or the QMConsole menu option on Windows) will be validated against the username used to log into the operating system. If security is not enabled, any user with a valid operating system username will be able to enter QM.

The details set for a user via ADMIN.USER also include options to enable or disabled specific features of QM that may have a bearing on system security. These are:

Create/delete accounts

Controls use of CREATE.ACCOUNT, DELETE.ACCOUNT and entering QM in a directory that is not already set up as an account.

A user register entry will be created automatically for a user entering QM on a system with security disabled who does not already appear in the user register. This entry will have all features controlled by security options enabled.

QM provides the ability for restrictions to be placed on which accounts a user may go into. The ADMIN.USER command can be used for each defined user name to create a list of accounts that is either those accounts that the user may access or those accounts that the user may not access. This mechanism is only meaningful when user level security is active (see the SECURITY command). Users with administrator rights are not subject to account restrictions.

•	Direct entry to QM from the operating system shell within an account directory.

•	Non-administrative users should be denied write access to the ACCOUNTS file in the QMSYS account otherwise they could set up alternative references to restricted accounts.

•	Restricting write access to the VOC file prevents creation of pointers to files in other accounts. Note, however, that some applications need write access to the VOC. Account barring of Q-pointers should provide effective security.

•

Ensure that the FILERULE configuration parameter does not allow the user to construct extended syntax filenames that access files in other accounts. The value of this parameter in the configuration file determines the initial rights but it can be reduced (typically in the LOGIN paragraph) for specific users or accounts.

•	Use the "Ban account creation" option of the ADMIN.USER screen to disable creation of new accounts by specific users.

A well designed application never allows an end user to reach a command prompt. This leaves restriction of what a user may do within the control of the application itself. Where it is necessary to provide differing levels of access to different users, QM provides several ways to identify attributes of the current user:

@IP.ADDR

User's IP address for network connections. This is also available in QMBasic as SYSTEM(42).

SYSTEM(27 to 30)

UID, effective UID, GID and effective GID (not Windows)

A user could potentially escape from the controlled environment provided by the application if the application were to abort. This can be avoided by a combination of the following techniques:

Disable the break key. The break key is automatically disabled until completion of the LOGIN paragraph unless it is enabled within that paragraph by use of the BREAK ON command. There should never be a need for use of the break key in a working application. In the unlikely event of needing to re-enable it for a specific user as a result of an application fault, the system administrator can use an extended form of the BREAK command to do this.

Use OPTION NO.USER.ABORTS to suppress all options through which a user can cause an abort to occur. This removes the A option from the "Press return to continue" prompt, the query processor pagination prompt and the break key options.

Implement the ON.ABORT paragraph. Despite the above techniques, an application may still abort as a result of a run time error or use of the ABORT statement within the application itself. When an abort occurs, QM discards all programs, menus, paragraphs, etc that are running in the process and returns to the lowest level command processor. Before this displays the command prompt, it checks in the VOC file for an executable item named ON.ABORT and, if this is found, executes it. A typical ON.ABORT paragraph terminates the user's session after, perhaps, logging the incident.

Some users such as application developers may need to be able to reach a command prompt. In this case, security subroutines can be attached to R or V-type VOC entries to provide control over what can be done.