The first ``layer'' of security you need to take into account is the physical security of your computer systems. Who has direct physical access to your machine? Should they? Can you protect your machine from their tampering? Should you?
How much physical security you need on your system is very dependent on your situation, and/or budget.
If you are a home user, you probably don't need a lot (although you might need to protect your machine from tampering by children or annoying relatives). If you are in a Lab environment, you need considerably more, but users will still need to be able to get work done on the machines. Many of the following sections will help out. If you are in a Office, you may or may not need to secure your machine off hours or while you are away. At some companies, leaving your console unsecured is a termination offense.
Obvious physical security methods such as locks on doors, cables, locked cabinets, and video surveillance are all a good idea, but beyond the scope of this document. :)
Make use of /etc/shutdown.allow to prevent someone
from rebooting your machine. This file is consulted when the machine
is rebooted using the Control-Alt-Del keys. It contains a list of
usernames that are authorized to reboot the machine.
Many more modern PC cases include a "locking" feature. Usually this will be a socket on the front of the case that allows you to turn an included key to a locked or unlocked position. Case locks can help prevent someone from stealing your PC, or opening up the case and directly manipulating/stealing your hardware. They can also sometimes prevent someone from rebooting your computer on their own floppy or other hardware.
These case locks do different things according to the support in the motherboard and how the case is constructed. On many PC's they make it so you have to break the case to get the case open. On some others they make it so that it will not let you plug in new keyboards and mice. Check your motherboard or case instructions for more information. This can sometimes be a very useful feature, even though the locks are usually very low quality and can easily be defeated by attackers with locksmithing.
Some cases (most notably SPARC and Mac) have a dongle on the back that if you put a cable through attackers would have to cut the cable or break the case to get into it. Just putting a padlock or combo lock through these can be a good deterrent to someone stealing your machine.
The BIOS is the lowest level of software that configures or manipulates your x86 based hardware. LILO and other Linux boot methods access the BIOS to determine how to boot up your Linux machine. Other hardware that Linux runs on has similar software (OpenFirmware on Macs and new Suns, Sun boot PROM, etc...). You can use your BIOS to prevent attackers from rebooting your machine and manipulating your Linux system.
Under Linux/x86 many PC BIOSs let you set a boot password. This doesn't provide all that much security (BIOS can be reset, or removed if someone can get into the case), but might be a good deterrent (e.g., it will take time and leave traces of tampering).
Many x86 BIOSs also allow you to specify various other good security settings. Check your BIOS manual or look at it the next time you boot up. Some examples are: disallow booting from floppy drives and passwords to access some BIOS features.
On Linux/SPARC, your SPARC EEPROM can be set to require a boot-up password. This might slow attackers down.
NOTE: If you have a server machine, and you setup a boot password, your machine will not boot up unattended. Keep in mind that you will need to come in and supply the password in the event of a power failure.
The various Linux boot loaders also can have a boot password set. Using LILO, take a look at the ``restricted'' and ``password'' settings. "password" allows you to set a boot-up password. ``restricted'' will let the machine boot _unless_ someone specifies options at the LILO: prompt (like ``single'').
Keep in mind when setting all these passwords that you need to remember them. :) Also remember that these passwords will merely slow the determined attacker. This won't prevent someone from booting from a floppy, and mounting your root partition. If you are using security in conjunction with a boot loader, you might as well disable booting from a floppy in your computer's BIOS, as well as password-protecting your computer's BIOS.
If anyone has security related information from a different boot loader, we would love to hear it. (SILO, MILO, loadlin, etc).
NOTE: If you have a server machine, and you setup a boot password, your machine will not boot up unattended. Keep in mind that you will need to come in and supply the password in the event of a power failure. ;(
If you wander away from your machine from time to time, it is nice to be able to "lock" your console so that no one tampers with or looks at your work. Two programs that do this are: xlock and vlock.
Xlock is a X display locker. It should be included in any Linux distributions that support X. Check out the man page for it for more options, but in general you can run xlock from any xterm on your console and it will lock the display and require your password to unlock.
vlock is a simple little program that allows you to lock some or all of the virtual consoles on your Linux box. You can lock just the one you are working in or all of them. If you just lock one, others can come in and use the console, they will just not be able to use your virtual TTY until you unlock it. vlock ships with Red Hat Linux, but your mileage may vary.
Of course locking your console will prevent someone from tampering with your work, but does not prevent them from rebooting your machine or otherwise disrupting your work. It also does not prevent them from accessing your machine from another machine on the network and causing problems.
More importantly, it does not prevent someone from switching out of the X Window System entirely, and going to a normal virtual console login prompt, or to the VC that X11 was started from, and suspending it, thus obtaining your privileges. For this reason, you might consider only using it while under control of xdm. At the very least, start X in the background, and log out of the console.