$Id: gtksct_requirements.html,v 1.3 2002/07/15 07:38:50 mulix Exp $
TOCgtksct is a GUI application, whose purpose is to allow defining rules for syscalltrack, injecting them into the kernel module, as well as storing them in files.
In addition, gtksct can be used to control various aspects of syscalltrack, e.g. loading/unloading the kernel modules, control the method of logging, etc.
The main function of gtksct is to handle rule lists. Rule lists could be loaded from either configuration files, or directly from the kernel (the 'active rules list'), and shown to the user. The user could manipulate the rules list, and eventually store it in a rules file, or upload it to the kernel.
A rule list should be shown in a table, sorted according to the rule ID. This is required, so the user will know the order in which the rules are matched. The rule ID itself does not need to be shown to the user - the rule name will serve as the identifier for the rule in the GUI.
From the list of rules, the user will be able to perform all the operations on the list - adding rules, deleting rules, re-ordering rules and the like.
When the user views the rule list, they may chose to add a new rule, at a given position in the rules list. Once the user stated (via some GUI gesture) their wish to add a rule in a given position, they will be prompted for information about the rule (including a comment for the rule). Once all information is added, the user has to click on a confirmation button, and then error-checking for the rule's data is performed. If there is an error, the user will get an error message, and be required to fix the error, or cancel the operation altogether. If there will be no error, the new rule will be added to the rule list in the position specified earlier.
In addition, the user will be able to add a new rule by cloning an existing rule. This is useful when wanting to add a new rule which is very similar to an existing rule in the list. The user will select a rule to clone from the list of existing rules, then active the 'clone rule' operation. This will show the rule's information inside the same GUI element used to adding new rules. From there, operation continues as if a new independent rule was added. Once the new rule is added, it is not related to the rule it was cloned from (i.e. modifying an attribute in the new rule, will NOT change the matching attribute in the original rule).
The user will be able to select a rule from the rule list, and activate the 'modify rule' operation. This will cause a GUI element, similar to that for 'add rule' to be opened, with the attributes of the chosen rule. The user will be able to modify the attributes of the rule as they see fit. When the user presses a confirmation button, the rule is checked similar to how that's done in the 'add rule' case. If the validation succeeds, the attributes of the original rule are modified.
The user should be able to select one or more rules in the rule list, and activate a 'delete rule(s)' operation. The selected rules will be deleted from the rule list.
The gtksct application should hold a list of operations that the user performed on a rule list, from the moment it was loaded, until it is closed. The user should be allowed to 'undo' any operation they performed, in reverse order. If operations were undone, the user can 'redo' any of them, unless they already performed another operation. When another operation is performed by the user, any 'undone' operations are forgotten, and cannot be undone again.
The user should be able to select the text of any rule attribute, as well as paste data into such a field. In addition, the user should be allowed to copy to the X selection, the full text of a single rule. This last option is useful for pasting single rules into email messages, for example, without having to save the complete rule list.
The gtksct application should support storing rule lists into rule files, and loading them from config files.
The format of a rules file should match the format supported by 'sct_config' - the command-line control application of syscalltrack. 'gtksct' should be able to read rules files written for use by sct_config, and be able to store rules files that 'sct_config' can read.
Saving to a file should be done in a human-readable format. This means that the file would contain proper comments, and the rules in it be formatted properly (rules spread over several lines, indented properly, empty lines separating rules, etc.).
Loading from a file should be done in a manner that preserves comments, as much as possible, in the same location they were written to. This means that loading a rule list from a file, immediately followed by saving it, should preserve the formatting of the file as much as possible. Specifically, a 'canonical' file format should be defined, under which saving a loaded rule list, will result an identical file. This could work, for example, by limiting comments to come right above the rule, guaranting one empty line between each pair of rules, and the like.
The gtksct application should allow the user to perform various control operations of syscalltrack's kernel part. This includes loading and unloading of the kernel modules, updating the active rule list, and controlling runtime behavior of the module (logging method, etc).
The user should be allowed to load and unload syscalltrack's kernel modules, as well as checking if they are active. If the user tries to unload the kernel modules while there are rules defined, the user should be notified of the situation, and prompted for confirmation of the unload operation. If the user confirmed the unload, the application should perform active rule list deletion from the module, and then unload the modules.
Note: when loading the kernel modules, the directory where to the modules resize should be stored in some configuration file, or assumed to be taken from a fixed directory of the currently running kernel (i.e. somewhere under /lib/modules/<kernel-version>/...).
The user should be allowed to update the active rule list, activating the 'upload rule list' operation on a rule list.
In order for this to make more sense, the user should be able to activate a 'download rule list' operation, which will get the active rule list from the kernel, and show it as a new rule list. The user could then manipulate the rules in the list, store it to a file, upload it to the kernel, etc.
The user should be allowed to control the logging method of the kernel. This includes specifying whether to log info via printk calls, or via the logging device. This also includes specifying parameters for this logging (e.g. when logging via the logging device, how to handle buffer overflow situations, etc.).
The application should allow users to conveniently view log files. This should include log files generated via 'printk', as well as log files generated via the logging device.
For printk-generated logs (which are actually records inside /var/log/messages), the application should filter-out only the messages generated by syscalltrack, and allow performing text-search operations on them.
for log-device generated logs, the application will allow showing them in a more structured format, once the log device supports that. This will allow showing the log records inside a table, sorting/filtering by a specific table column (e.g. show only the log records where the UID was '0'; or show only the log records for the 'open' system call). Note that the number of columns in the table may be affected by the log format - if there is no info about the UID, for example, a UID column should not be shown. The user should also be allowed to control which columns to be shown in the table. Of-course, the user should still be able to view the full contents of a given log record.
A few issues should be taken into consideration when doing the high-level design of 'gtksct', and its user-interface specification. These issues relate to features that will be added to the application in later versions - and which the current design should take into account, to avoid forcing a re-write later on.