...making Linux just a little more fun!
The situation can typically arise at an educational institution or in a training environment where a general purpose (Linux-based or not) computer laboratory is set up to allow student users access to a lab machines, but not super user (root) access. The machines will typically be set up via the BIOS to boot to the hard drive first, so that the systems cannot be subverted by inserting a bootable CD ROM or bootable floppy. Of course, a BIOS password is required in order to change BIOS settings. However, there will often exist a group, e.g. an advanced operating systems class, where Linux is required and super user access is essential. It is undesirable to give this group super user access to the regular system or BIOS password access.
We would like to at least achieve a set-up where the normal users of the computer laboratory can conduct business as before while the advanced users can boot into a separate configuration where they have super user privileges. We do not want the advanced users to require root access to the the configuration for normal users, because the advanced users will be routinely modifying and occasionally breaking the system. In summary, the goal is that
The proposed solution is to be implemented by the system administrator, who has super user access, knowledge of needed passwords, etc. Once the solutions are implemented, the system administrator can once again go hide in his/her cave. We start by modifying the BIOS to boot the system with a bootable CD. For our case study, we chose Xubuntu-6.06.1 as our bootable CD. The 6.10 version is not yet available at this writing. Xubuntu, not using KDS or Gnome, presumably has somewhat smaller footprint than the equivalent Ubuntu or Kubuntu versions. This could be important since our ultimate installation target is a USB micro drive (USB-MD). It may also run a bit faster on that hardware target than its more top heavy cousins, which is also an issue with today's 3600 RPM USB-MD.
Our solution assumes that the machine to be used allows booting from the MBR of the USB-MD when the BIOS is appropriately configured. In this case, we place a master boot record (MBR) on the USB-MD. The advanced user can then insert this USB-MD into a laboratory computer and reboot the system into Xubuntu. A normal user has no such USB-MD and when a reboot is attempted the system will boot first from the hard drive MBR, hence into the normal operating system configuration.
Some Advantages:The first disadvantage is ameliorated if the laboratory is a teaching laboratory holding no sensitive data, essentially just information (e.g. configuration, applications) that would be inconvenient to reconstruct from the backup media. Further, if malice is not present, there is little likelihood that the machines would be compromised. It is assumed, for example, that the Xubuntu installation on the USB-MD would be configured so that it would not automatically mount the hard drive partitions at bootup. So the advanced user would have to overtly violate the laboratory protocol to compromise the normal system. The second disadvantage has various cures. We already mentioned overt modifications such as using a different /etc/X11/xorg.conf for different target machines. Perhaps more attractive would be to employ a USB-MD with large enough capacity to create two Xubuntu installations - one for the laboratory environment and the other for home use. Whichever one was booted should also mount the other, for easy data transfer and backup. Alternatively, the two separate installations could share a common /home directory in its own partition. At this writing, for this author's purposes, a 10 GB USB-MD would appear to fit that purpose nicely. Maybe one will appear at birthday time.
The bootable CD with a companion USB stick for storage is also a potential solution, but doesn't work as well for the problem space envisioned. For example, if kernel recompilation and redeployment is an area of investigation (e.g. investigating the implementation of new system calls) or if changing major portions of the root file system are fair game, one either burns a new CD to try the results or moves more and more of the system to the USB stick. Because the USB has a more limited capacity, the USB-MD solution rather naturally evolves.
Another possibility is just to make the laboratory machine dual/multi boot, so it can boot into the 'normal user' Linux or the 'advanced-user' Linux. There are several serious drawbacks. First, the advanced user cannot change the USB-MD boot configuration for grub (or lilo) because that resides on the hard drive and requires super user privileges. Of course, the advanced user merely needs to boot the USB-MD and mount the hard drive to make such changes. However, our protocol is to avoid having the advanced user mount the hard drives, to prevent inadvertent damage. Second, the normal user can boot into the 'advanced user' Linux. This would likely be unsuccessful, but is still undesirable.
Perhaps yet another solution involves virtualization. This may ultimately be viable, but the author's current understanding of one such approach, Xen Virtualization, indicates that within the sandbox of a sub domain the user may be given super user privileges, but such tasks as kernel recompilation and redeployment will require super user access at the hypervisor level.
The case study was conducted in the Computer Science department at Malaspina University-College in Nanaimo, BC, Canada. The Linux box used was one from a recently configured laboratory. The USB-MD was the property of the author.
The salient hardware details are these:
Linux box vendor -> recent Seanix purchase BIOS vendor -> Intel BIOS version -> NT94510J.86A.3813.2006.0411.1332 USB-MD vendor -> T-one USB-MD capacity -> 5 GB
The basic steps here are
[Note: Xubuntu should also provide an option to install to the hard drive, which we do not want here.]
When the USB-MD installation has completed, choose to reboot the system, removing the CD at the appropriate time (typically, it will be ejected). At the very start of reboot, enter the BIOS to ensure that the system will reboot from the USB-MD first. The reboot may take several tries in order to get the BIOS settings just right. For the Intel BIOS referenced above, the choices in the BOOT sub menu were these. Not all are salient, but the following choices worked:
| boot Menu Type | Advance | |
| Boot Drive Order | USB-MD CD Floppy Hard Drive |
|
| Boot to Optical Devices | Enable | |
| Boot to Removable Devices | Enable | |
| Boot to Network Devices | Disable | |
| USB Boot | Enable | |
| Zip Emulation Type | Hard Disk | |
| Boot USB Devices First | Enable | |
| USB Mass Storage Emulation Type |
All Fixed Disk |
Different BIOS vendors will provide different choices and wording, but the above gives the idea.
The file /boot/grub/menu.lst installed by Xubuntu on the USB-MD for booting the Seanix machine was as follows (except for editing of the title line):
title Xubuntu 6.06.1 on USB_MD root (hd0,0) kernel /boot/vmlinuz-2.6.15-26-386 root=/dev/sdb1 ro quiet splash initrd /boot/initrd.img-2.6.15-26-386 savedefault boot
The Seanix hard drive (scsi) was seen as /dev/sda. It was also recognized first in the BIOS bootup, whether or not the hard drive MBR was chosen to boot Linux. This could then be used to boot up into the USB-MD via the MBR on the USB-MD.
The author's home machine already had a version of Kubuntu (one of Xubuntu's heavier cousins) installed. It differs from the laboratory Seanix machines in these important aspects:
These differences needed to be addressed and were dealt with as follows:
The new stanza for the USB-MD interjected into the /boot/grub/menu.lst on the hard drive was:
title Xubuntu 6.06.1 on USB_MD root (hd1,0) kernel /boot/vmlinuz-2.6.15-26-386 root=/dev/sda1 ro quiet splash initrd /boot/initrd.img-2.6.15-26-386 savedefault boot
With this new stanza and the proper replacement for /etc/X11/xorg.conf, the USB-MD could be booted from the home machine. Note that this is the dual/boot solution rejected earlier for the laboratory machines. However, we assume that the home machine does not need to protect different user groups from each other.
The bootable USB-MD is an acceptable solution where general purpose labs can provide convenient access to
while keeping a hardware separation between the two groups. Once the system is implemented, it requires virtually no extra care or feeding by the system administrator.
The solution does compromise security somewhat, which is acceptable for the typical general purpose teaching/training laboratory where sensitive data are not stored and where the advanced user is trustworthy.
Talkback: Discuss this article with The Answer Gang
![[BIO]](../gx/authors/sevenich.jpg)
Dr. Richard Sevenich, Professor Emeritus of Computer Science, retired from Eastern Washington University early in 2006. However, intending to remain active, he is currently teaching Computer Science on a part time basis at Malaspina University-College, in Nanaimo, BC, Canada. His teaching and research interests lie in the areas of Operating Systems, Compiler Design, and industrial control via state languages. He writes occasional articles on these and other topics. He has used Linux since the summer of 1994.
