


Secure and Robust Computer Systems for Primary and Secondary Schools

By Richard A Sevenich and Michael P Angelo

A wealthy school district will have the option of purchasing new software and hardware at some appropriate interval. It may also have the technical staff to install and maintain the hardware and software. Even in this idealized school district, the computer system environment is a harsh one, with its many student users, some of whom start as relatively computer illiterate and may not have acquired the discipline to follow administrative rules intended to ameliorate system virus infections and other external attacks on the system. The technical staff has the added burden of attempting to maintain system security in this nearly impossible environment, characterized by intermittent, unplanned intense work shifts in response to system security disasters. Providing the necessary level of technical expertise is quite expensive and consequently rather rare in our school systems. In fact, many of the primary and secondary schools in the USA have computer facilities that are in dire straits. Perhaps the major problems are these two:

Let's consider each of the two problems in more detail. Cleaning a network of virus infections is a time-consuming thankless job. Making a system in a school environment virus proof in practice is probably not possible currently. Other hostile system attacks (even internal) are quite likely. A teacher who depends on such a system to be consistently available will be routinely disappointed.

If we focus on the second problem, these are its consequences:

In this note we propose a straightforward solution. The idea came to us when we began playing with version 3.0 of Demo Linux ( It provides the start of a solution. When you boot a machine with Demo Linux, you end up with a machine running Linux from the CD. The network will be configured as will X Windows. The old Star Office 5.2 is also included. The hard drive may be mounted. We had remarkable success booting a variety of machines, including laptops, from the Demo Linux CD.

Forgetting about the hard drive for the moment, a school could have such CDs in all their computers and turn them on each morning to start with a virus-free environment, compatible software in all machines, and no licensing problems. Rather than requiring the constant application of security patches, the system is reborn each day. The solution is not expensive and is ultimately robust due to its simplicity. Well, it is almost that simple and convenient, but not quite. Here are three drawbacks:

  1. Some system configuration (e.g. network parameters) is needed at each boot, requiring that somebody knowledgeable make the appropriate entries. This is time intensive when the number of systems is large - assuming that a knowledgeable person is even available.

  2. The hard drive remains a virus target.

  3. Applications running from the CD will run relatively slowly; perhaps unacceptably slowly on some machines.

We next suggest solutions to each of these problems.

  1. Automate system configuration at boot. To implement this we would add a feature to a clone of Demo Linux. In particular, on the very first boot have the system configuration choices made by the appropriate sysadmin or technician and then have the system automatically hard code those choices by producing an ISO image to be burned onto a new boot CD, tailored to that specific machine. The new boot CD would automatically configure the system as desired. Boot CDs could be updated on whatever schedule the administration would deem appropriate (e.g. once a year in August).

  2. We'll assume that the machines at the school do not have an NFS/NIS file sharing setup. If that assumption were wrong, we would do things a different way, We'll further assume that when this new system is first installed, the hard drive is ours; i.e. any files stored on the hard drive have been archived by the owner. We'll propose a severe solution and insist that machine users either save their daily work on a floppy or transmit it (e.g. via scp) to a secure machine serving as a repository. The description of that secure repository machine is outside the scope of this discussion. Copying work to a floppy or transmitting it to a secure repository would be made reasonably convenient and intuitive; e.g. via some GUI interface. The CD boot process would clean all the prior day's files from the hard drive. This is the aforementioned severe solution and more involved and intelligent solutions might be contrived. However, this solution appears to guarantee a virus free environment at each new boot and is simple. Note that the hard drive cleaning is not all that time consuming because it involves only those files created since the previous boot.

  3. Application speed can be enhanced by having the boot CD move the appropriate applications to the hard drive during the boot process, after the hard drive has been cleaned as described in the prior step.

It must be admitted that this approach is not going to produce a well performing system for very dated machines with limited resources. Open Office, for example, would not perform well. A small footprint Linux version and other resource-conserving software could prove viable. Such are available in the embedded Linux world and could be adapted to resource-limited machines. This may be too small a market to pursue, however.

We've explored the preceding ideas for feasibility, tailoring and burning some boot-up CDs and the like. However, we have various other commitments and cannot take the concept to full fruition as a polished, flexible product in a reasonable time frame, although we will continue to work on it. We see this as having the potential to:

Pretending that such a product will actually be created, there is the one remaining hurdle - the initial deployment. School districts with technical personnel could easily handle the initial CD boot and the creation of the second, machine-specific boot CD. The cost of the initial installation would be amortized very quickly. Alternatively, the CD provider might supply on site initial installation services at a reasonable cost. Because of the open nature of Linux, other consultants would become available. Finally, financially hard-pressed school districts might get such services free from a nearby Linux User Group.

Teachers, already overburdened, will need to learn enough Linux to function. They will be resistant, because their time is precious. Those of us who switched to Linux at some point in the past had to travel a learning curve. However, Linux has progressed to the point where the learning curve is no longer significant. There are distributions that are configured to look and act rather like the Microsoft interface. Old Microsoft Office files can, in most cases, be imported into something like Open Office and so on. The direct benefits to the teachers should outweigh the slight pain of conversion.

We haven't seen this concept in this form in print before, although all its elements are out there. Hence, we wanted to put it before the Linux community. If the proposal bears up under scrutiny and appears viable, we hope some entity, such as the Demo Linux folks or a Linux distribution, with appropriate expertise and resources, adopts it as a project. We have posed it as a solution to certain difficult problems typically faced by school districts in the USA. Obviously, it could be applied in other areas. To some extent, time is of the essence - the need and opportunity are there now.

Copyright © 2002, Richard A Sevenich and Michael P Angelo.
Copying license
Published in Issue 81 of Linux Gazette, August 2002
