|
|
This section gives tips on how to build FMLI applications that prevent unauthorized users from circumventing access controls or mechanisms that protect sensitive system operations.
An FMLI application may allow users to access UNIX system executables by escaping to the shell, either with the ! shell escape or the unix-system command, or by selecting a menu item or SLK for which the action coded invokes an external executable. It is your responsibility to make sure these means of access are not abused.
Both means of escaping to the shell can be disabled if necessary. When the nobang descriptor is defined and evaluates to TRUE, users cannot use the ! shell escape to invoke external executables. Nor will they be able to invoke the open command from the command line. That means the user cannot, for instance, create a menu that invokes an external executable and open it to gain access to the shell. You can disable the unix-system command as described in ``The commands file''. Keep in mind that disabling the command will also make it unavailable to your own FMLI scripts.
FMLI does not try to second-guess your application by setting shell variables such as PATH or IFS. It leaves it to you to insure that the execution environment is correct, and that the correct executable will be found. Similarly, it is your responsibility to make sure that any commands you add or redefine in the commands file perform as expected and do not violate security principles. For discussions, see ``Application level definition files''.
By default, FMLI commands and executables invoked through FMLI (except those running under a full-screen mode executable) are not interruptible. If you enable interrupts for some or all parts of your application, you must insure that not completing the interrupted action will not compromise the system and that oninterrupt is defined such that the appropriate recovery actions are taken. The risks here include leaving sensitive data files or incomplete or inconsistent data on the system after the unfinished operation. You need to weigh these risks against the ``friendliness'' of allowing interrupts. At the very least, interrupts should be enabled at the lowest possible level, rather than for the whole application. The oninterrupt in effect should always be the appropriate one. It, too, should be defined at the lowest level of the hierarchy. For a discussion, see ``Interrupt signal handling''.
FMLI uses four distinct types of variables, each of which can produce unexpected results if handled improperly.
UNIX system shell environment variables are inherited from the invocation environment and can be modified with the set and unset built-in utilities. The effects of any modification are visible to child processes of the application.
File-based variables are stored in and read from the file that is part of their name, so that multiple applications or sessions can share data.
So-called local variables are local to FMLI but global within the application. Any line that references $foo, for example, will reference the same value; changing the variable's value in one frame changes its value in all frames. For this reason, extreme care should be taken to avoid name collision when developing applications, especially when there is more than one programmer involved. For this reason, too, you should be sure to implement validation tests with appropriate criteria when using FMLI's mechanisms for validating user input. In particular, if you set a variable based on user input in one frame and reference it in another, the data may be valid at the time of entry but not at the time of use. For a discussion and example, see ``Validation of form fields''.
Built-in variables are read-only variables that are visible only within the FMLI session. Some are maintained on a per-frame basis and have different values in each frame. Others are visible throughout the application.
There are two ways to dereference a variable. ``$''VAR parses the variable once. ``$!''VAR reparses the variable as long as it contains special characters. That is, if you set VAR to `pwd`, $VAR is `pwd`, whereas $!VAR may be /home/chris. You should never use the $! notation when referencing built-in variables because it is impossible to guard against users entering special characters in fields. Note that if the initialization file descriptor use_incorrect_pre_4.0_behavior is set to TRUE, the first form implies the second. For discussions, see ``Variables''.
By default, FMLI determines how often descriptors are evaluated. You can use the const type cast to make sure that a descriptor is evaluated only once, no matter how many times it is referenced, or the vary type cast to make sure that a descriptor is evaluated whenever it is referenced. Use these casts with care. In particular, do not use const if the data could become out of date, that is, unless you know that the descriptor value will be the same no matter how many times it is referenced, or are certain that the first value must be retained (a startup-time value, for example). For a discussion, see ``Descriptor evaluation''.
Co-processes for trusted applications should use named pipes created by the application with the appropriate permissions; the default pipes created by FMLI are readable and writable by everyone. Handshaking can also be used to enhance security. For a discussion and examples, see ``Using co-processing utilities''.