[413] in linux-security and linux-alert archive
Re: console security (was Re: problem wi
daemon@ATHENA.MIT.EDU (Zygo Blaxell)
Wed Oct 11 14:47:56 1995
From: Zygo Blaxell <zblaxell@calum.csclub.uwaterloo.ca>
To: tytso@MIT.EDU (Theodore Ts'o)
Date: Wed, 11 Oct 1995 11:02:41 -0400 (EDT)
Cc: RDMiller@legislate.com, kjh@seas.smu.edu,
owner-linux-security@tarsier.cv.nrao.edu,
linux-security@tarsier.cv.nrao.edu
In-Reply-To: <9509281758.AA02870@dcl.MIT.EDU> from "Theodore Ts'o" at Sep 28, 95 01:58:51 pm
Quoted from Theodore Ts'o:
> That being said, if you look at the comments in the kernel sources
> regarding the SAK, you will see that I am very well aware of its
> shortcomings. A really correct implementation would require the help of
> specialized code in /etc/init, to do things like restore the default
> font, keymappings, etc. It turns out, though that you still can't do a
> perfect job, due to the brain damaged way that video modes that handled
> by the Linux system. That is to say, user programs are responsible for
> saving and restoring the contents of the video registers, *not* the
> kernel. Hence, it's basically impossible for the kernel for the kernel
> to reset the video mode to anything sane when the SAK is pressed.
>
> The right way to do things is that the kernel should be responsible for
> setting and resetting the video modes, and all the programs that
> currently muck with such things (X11, dosemu, svgalib, etc.) would rely
> on kernel calls to do their work. This has the further advantage that
> programs that rely on svgalib no longer need to be setuid root, and that
> buggy X servers, dosemu, and svgalib programs can no longer render the
> console to be useless, requiring a reboot to fix things.
Oh, I don't know about this. The 'resize' code that's distributed with
kbd is capable of recovering from all sorts of nonsense that Dosemu
and XFree86 do to my consoles (I even have a dedicated perl script on
tty2 just to kick the console back into text mode--it does lose the
contents of every console, but it at least makes the console usable).
Ditto for fonts and palette registers. You can come to a reasonable
approximation of reloading the keyboard maps using loadkeys. A quick
shell script that does that, reasserts 'text' mode on the keyboard, and
exec's getty can do the job to cleaning up the mess after SAK without
modifiying init or getty.
A neat side-benefit of having SAK blow away XFree86 with extreme prejudice
is that when you exit X window sessions you don't spend minutes swapping
in megabytes of X server data just to erase windows from the screen.
It's more secure, faster, and more reliable than letting XFree try to
restore what it thought was the VGA settings before it was invoked.
On most hardware putting more functionality in the kernel would be the
most elegant thing to do; however, with an Intel-based platform with
N+1 video cards available, the kernel will only ever have as many as N
video drivers...
> The main reason why no one has done any of these work? Probably because
> in 99.7% of the Linux boxes out there, console security is basically
> pointless. If you have access to the Linux console, you probably also
> have access to the computer --- specifically, you can probably insert
> your own boot floppy, and reboot the machine by hitting the magic "big
> red button", or simply by power cycling the machine.
>
> It's possible to close off some of these holes, if you have a BIOS that
> allows passwords (although someone has already posted the routine that
> will allow you to retrieve the password from the CMOS for AMI BIOS's),
> AND you can disable booting from the floppy, AND you don't allow any
> other OS, like DOS, to be booted from LILO, AND you configure LILO so
> that the user can't specify arguments to the boot command, AND the CPU
> box is locked up so someone can't open up the case, and blast the
> contents of the CMOS.
>
> However, most of the time people just don't care about console security.
> If you're running Linux as timesharing machine (or a dialup server, or a
> PPP server, or whatever), it wants to be locked up somewhere where you
> can provide good physical security for the machine. If you're running
> it as a single-user workstation, then console security isn't important.
Hmmm...close to 99.7% (gratuitous statistic) of the Linux boxes planned to
be deployed at a well-known university I used to be affiliated with are
multi-user workstations (that is, they service many users, but usually
only one or two at a time). The machines meet all of the criteria above
(the metal spike through the case prevents theft as well as making it
hard to open ;-). The major issues that have blocked the widespread
deployment of Linux in the past (performance, reliability, and support)
are disappearing rapidly as Linux matures, and the problems that are left
are training and security issues. In an environment where the seats
in front of the terminals rarely get cold, console security is not to be
ignored.
> There are some rare cases where console security is actually important
> in real life. However, these are the execption, not the rule. That's
> why I never bothered taking the SAK code any further than where I had
> left it. If someone wants to take it further, be my guest! However, be
I would like to, but my implementation of a more secure console got
rejected (something about requiring root privilege to do anything that
wasn't in VT220 protocol... ;-). I agree that requiring superuser access
to remap _any_ key on the keyboard is a bit restrictive; nonetheless,
I'm desparate for any way to prevent a user from being able to map
_every_ key on the keyboard, and requiring superuser access to do it is
close enough for this 0.3% of people. ;-)
It would be nice if there was even the _option_ of extra security in the
standard kernel. Perhaps all of the "evil" ioctl calls could be moved
to some device file (where an ioctl is "evil" if it can interact with,
prevent the interaction with, or change the user interface to more than
the one console upon which it is invoked). This would allow
administrators to set their own permissions--666 for the current
behavior, and 600 for the paranoid.
I was very impressed with the way my concerns with the screen-dump
ioctls were addressed. /dev/vcs* is a _really_ nice interface compared
to the old ioctl(); it enhanced security, added configurability, and I
got to throw away yet another Linux-specific utility program ('screendump'
obsoleted by 'cat').
> warned that the number of people who will find it useful will be
> relatively small, and it's not going to be easy. Many people will
> therefore probably find it not worth doing (unless of course they need
I get paid to increase security wherever it doesn't get in the way of
real work...(lousy job, someone's gotta do it ;-). I find it worth
doing, and do it every time a new kernel comes out. :(
> it themselves for their own application --- in which case they should be
> warned that they had better think about other ways that someone with
> access to the console can break into their system).
We don't use NFS, network services without cryptographic authentication,
setuid programs, or mount /proc or removable media in our most secure
servers. Console security really is a bit of a weak point right now--the
one thing I can't do is prevent people from creating their own binaries
(kinda sucks when you are in the business of developing software), so
I can't prevent users from generating VT ioctl calls. With the number
of transient employees increasing, and the extreme value (at least
on paper) of some of our data, we can't afford to have people leaving
trojans running on popular workstations when they leave for the day.
Buying more machines so permanent employees can have their own terminals
would be nice, but a quick patch to the kernel is cheaper than half a
dozen Pentium boxes.
Incidentally, SAK is broken in 1.3.30 for the console :(. Gets a NULL
pointer dereference and kills the keyboard interrupt handler, but
otherwise keeps running. If anyone needs more info I'll do it again and
get the addresses.
