Security

[NOTE: This section is out-of-date. See the Security Considerations section of the PIKT Reference for the latest information.]

The current PIKT security model is fairly trusting. There are things you can do now to tighten security, while other things--Kerberos-style client-server authentication and data encryption, for example--are under study and planned for implementation in the near future.

In PIKT.conf, which functions roughly like a .rhosts or .shosts file, you set various access parameters (e.g., uid, gid, master, domain, master_address, etc.) and service rights (e.g., all_services, kill_service, install_service, etc.). By careful and judicious use of these settings, and in combination with other measures (firewalling, running piktc_svc only when necessary, etc.), you can achieve a level of security sufficient in many situations.

When you issue a piktc command, the slave (remote) host and requested service are registered with the master (local) piktc_svc. Upon receiving the service request, the slave piktc_svc checks its local access authorizations in PIKT.conf. If the service request is authorized, the slave piktc_svc then does a "callback"--a second, independent TCP connection --to the master piktc_svc, seeking to verify the request. If it verifies-- i.e., both slave host and service request match--only then does the slave piktc_svc perform the requested service. It then returns the outcome of the service request to the requesting piktc. Finally, the slave host and requested service are deregistered on the master piktc_svc. Please see Figure 1.

Figure 1: callback

        MASTER                            SLAVE

        piktc<------------------------------+
          |        (2) send request         |
          |        (7) return result        |
          |                                 |
          | (1) register slave & request    |
          | (8) deregister slave & request  |
          V                                 V
        piktc_svc<---------------------->piktc_svc 
                   (4) callback            (3) check authorizations
                   (5) reply               (6) perform service

piktc and piktc_svc do complete service request logging, and piktc_svc marks denied requests as "ERROR". It is not difficult to set up log monitoring scripts (and scripts to monitor the monitoring scripts, etc.) to spot attempted security break-ins. Remember that you can log to syslog and special logs, and dump to a printer, besides sending out e-mail alerts. Scripts can also call pagers in security emergencies. You can even have a monitoring script kill the local piktc_svc under suspicious circumstances.

You can use PIKT for security in at least the following six ways:

As just a centrally managed scheduler. Have piktd invoke your preferred security tools according to the schedules in piktd.conf.
The above, plus have PIKT manage other security tools' config files (the inevitable per-machine and per-OS customizations).
All of the above, plus use PIKT #ifdef's to activate and deactivate different security tools as changing conditions warrant.
All of the above, plus use PIKT to handle your security log file analysis and incident reporting.
All of the above, plus employ PIKT alarms and data objects as supplements to the standard tools. (For example, have PIKT do things that COPS or Tiger don't do.)
Use PIKT exclusively.

PIKT is especially adept at points one, two, and three above.

As for point four, there are good solutions out there already for analyzing your security log files, but PIKT might be superior due to its more powerful and flexible built-in scripting language.

As for point five, extending one tool requires you to learn Perl, another to get intimate with the Bourne shell, while five others require you to learn five different cryptic and proprietary command languages. Learn those languages and modify those tools on their own terms where that makes the most sense, but when sensible resort to PIKT.

As for using PIKT exclusively, in spite of its great virtue of involving just one system and command language to learn and use, I don't propose that PIKT do everything! For many purposes, there are some really excellent alternatives available. I therefore suggest that the optimum solution lies somewhere around points three, four or five.

Security should be systematic, flexible, and easy to manage. These are areas where PIKT excels. At the very least, PIKT is a general framework on which to build your security efforts.

1st page