Console Secuity Intro Insuring the security of a system that someone unfreindly has access to is a difficult problem with no real complete solutions. Once a person has physical access to a machine, there is almost nothing that the software can do to prevent the machine from being compromised. However, there are some tricks and techniques that can be used to at least slow down a potential threat. Focus This howto is primarily geared towards x86 based pcs. Other platforms have different console access configuration properties. Nomenclature For the sake of this info, physical access to the machine will be refered to as "console access". The amount of physical access a user has to a machine can be more fine grained that that of course (ie, a machine with a monitor and keyboard accessible, but the cpu/drives locked away somewhere). Typical Default Config Most linux distributions ship with very little console security features enabled. There are several reasons for this. The most common is that most linux users currently are home users using the machine is a mostly secure enviroment in a non multi-user enviroment. Another common reason is that setting a box with a hightened level of console security makes a machine harder to "rescue" if need. It is pretty common practice for new users to forget their root passwd, or overwrite LILO, or do something else that can only be easily fixed in an enviroment where console security is lax. Potential Threats Ability to reboot or Halt a machine Most pc's are designed to be easy to reboot or shutdown. Historically, it was just "The big red button" on the front of the machine, but recently many PC include buttons on the keyboard and even software hooks to make shutting down or halting a machine easier. Definately not something you want in a hostile enviroment. Single User or Maintence modes Linux and most unices include a "single user" or maintence mode where a machine can be booted up into a bare bones non-multiuser, non-networked envioroment for administration purposes. Most linux PC allow the user to reboot the machine and pass LILO the option: linux s TO boot into single user mode. This allows whoever rebooted the machine to get a root shell on a machine with full administrative access. Installation of software including trojans/viruses/backdoors/etc A user sitting in front of a machine can often upload software to the machine even if the machine is completely isolated from a network. Typically this means using a floppy or cdrom to install additional software. Taking of sensitive data Just as a user sitting at a machine can install new software, they can also copy data or information off of the machine and onto external media. Destruction of Sensitive Data In many cases it can be easier to destroy important data than to copy or move it. This can range from the sophomoreic `rm -rf /` , to actually physical attacks on hardware. A rusty nail across a drive platter is crude, but effective. Forgery, impostors, and masquerading. If someone sits down at a machine, and sits at the consoled some other user is logged into, for all practical purposes they can pretend to be that user. The impostor at that point has access to ssh keys, pgp private keys, and other info that may be needed to send false emails, launch attacks on other systems, etc. If a coworker got an email from you from your machine, asking for some passwd on some machine, would you give it to them? Invasion Of Privacy Just as a user sitting at someone else's console can pretend to be that person for masquerading purposes, they can also just as easily read personail mail, schedules, date books, contact lists, and other personel info. Prevention There are two halves to console security. One is software, the other is the physical security of the machine itself. Physical security is of course, far beyond the scope of this info, but I'll attempt to hit some of the highpoints. There are several things you can do under linux to make a system more secure. Used in conjunction with a good physical security practices, and a user can feel reasonably assure their data is safe. Software Tools LILO lilo is probabaly the most useful software tool for restricting access to a box. By default, lilo is setup to allow anyone who is sitting in front of the machine when it reaches the lilo prompt to choose run levels, pass kernel parameters, etc. It doesnt ask for any authentication at all. This of course, is not a good thing. Any user can launch the box into single user and have full root access to all the filesystems on the machine. They could also theoreticaly also launch the kernel with harmful kernels paramaters. But the primary concern is making it difficult for a unauthorized user to change run levels or alter the way a system boots. The best source of information for lilo configuration is definately the llilo README. This is typically stored in /usr/doc/lilo or is available in the lilo source distribution. In particular, the section on "General per-image options" offers instruction on setting up lilo to ask for a passwd. There are a few lilo options that will request a passwd. I'll hit the standard setups. * Requireing a passwd on every boot up. If you want lilo to ask for a passwd on every boot or reboot, you just need to add the global option "password = fooBar" replacing fooBar with the plaintext version of the passwd. A few things to note about this. The password is in plaintext in the lilo.conf file, so this files needs to be chmod'ed so that it is only readable by root. To do this, issue the command: chmod 0600 /etc/lilo.conf A sample lilo.conf to do this, borrowed from the lilo README. password = Geheim single-key image = /vmlinuz label = linux alias = 1 other = /dev/hda1 label = dos alias = 2 After setting up lilo, you will need to run the command: /sbin/lilo The other thing to note is that, this will make unattended reboots impossible. Someone will have to be at the console who knows the passwd to boot the machine. * Requireing a passwd only on "non-default" boots This is probabaly the most sane setup. As long as their is no user interaction at the lilo prompt, lilo will not ask for a passwd. This allows for unattended reboots, but if anyone attempts to boot into a different run mode or attempts to pass kernel paramaters, it will ask for a passwd. The same note about the file needing to be read only applies here as well. A sample config nicked from the lilo README. password = Geheim single-key image = /vmlinuz label = linux alias = 1 restricted other = /dev/hda1 label = dos alias = 2 * Changing partion types with lilo Lilo has an often unused ability to manipulate the partion table of your drives at boot time. This can include marking partions bootable, and or chaning the filesystem types. Why would you want to be able to do this? Changing partions to obscure or incorrect partion types is a easy way to lead some people off the trail when they are snooping around your system. It's definately in the "security though obscurity" category, but if your very paranoid, the extra step or two an attacker has to go though to find your data may be worthwhile. This is more useful in a situation where perhaps a user has a stanadard boot that they dont want a particular partion viewable to the casual observer, and another boot setup that makes it accessiable. A partion with sensitive data could be configured to be be hidden under a normal boot setup. Note that "hidden" is a bit of a stretch. The file system is just given a different partion type id, so most normal config wont see it, but the data is still there in its orignal form. A root user could fdisk the drive, see the partion, guess at its correct type (ext2? dos? minix?), and mount the disk and read it. This is purely a obscurity step. Xlock/Xscreensaver If you dont want any random user to be able to sit down at your X session and peek away, you need to be able to lock your display so that users can not take it over. The standard apps for doing this are Xlock, and Xscreensaver. Both include screen locking mechanisms, and screensaver configurations. Both should be fully PAM aware too. Caveats: on normal linux configs, a user, particulary a root user, can change to a virtual console (ctrl-alt-F1 for example), and get a login screen or a console perhaps. It is also standard practice for a user to be able to kill X entirely with the ctrl-alt-backspace command. If the user started X from the command line, this will kick them back to the login shell. More info on how to prevent this in the X configuration section. XFree86 Configuration The most important aspect is setting up so that arbitrary users cant kill X and return the user to a console. The danger with this is that a someone could kill a users X session, even if they are running a screen locker, and get access to a shell in the worst case, or thrown back to gdm if in run level 5. Both are essentially local "denial of service" attacks. Letting any user kill all the apps another user has open at the moment with a simple key combo is not good. In XFree86, this can be turned off by just adding the "DontZap" option to XF86Config. Another thing to try is instead of using `startx` to launch an X session from run level 3, you can use the command `exec startx` (at least under bash). If X is started this way, when the user exits the X session, they will be returned to a login screen. The shell that X was launched from is closed. init The main thing to be concerned with init is users's ability to change runlevels, or to reboot the system. By default, most systems only allow root to change runlevels, so this isnt too big of a concern. However, essentially any user can press ctrl-alt-delete, which gets captured by init, and whatever configuration /etc/inittab is setup to do gets ran as root. To disable this, either just comment the line out, or set it to run something harmless when ctrl-alt-delete is pressed. vlock vlock is a terminal "locker" for locking down consoles or terminals. The useage to lock the current console is: vlock This will not clear the current console, so it is probabaly advisable to always run `clear; vlock`. I would suggest making an alias for this. To lock all virtual consoles, a user can issue the command: vlock -a This will lock all consoles, and not allow a user to switch to other vc's. Caveats: if used on a vga or fbcon console, it may be possible for a user to use "shift+pgup/pgdn" to scroll back in video memory and see the last few screenfuls of text. For the time being, the best thing is to lock the current vc, switch to another vc, and swith back. autorun/magicdev For a system where console security is a concern, these applicatison need to be disabled. They allow a user to insert a cdrom with arbitrary code on it, and have it executed as that user. This could be used to kill screensavers, vlock, download software, etc. ============ BIOS Configuration =========== Bios passwd Disable floppy/cdrom booting No netboots