[418] in linux-security and linux-alert archive
Re: console security (was Re: problem wi
daemon@ATHENA.MIT.EDU (Zygo Blaxell)
Sat Oct 14 11:02:18 1995
From: Zygo Blaxell <zblaxell@calum.csclub.uwaterloo.ca>
To: tytso@MIT.EDU (Theodore Ts'o)
Date: Sat, 14 Oct 1995 06:39:45 -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: <9510131852.AA25617@dcl.MIT.EDU> from "Theodore Ts'o" at Oct 13, 95 02:52:23 pm
Quoted from Theodore Ts'o:
>
> From: Zygo Blaxell <zblaxell@calum.csclub.uwaterloo.ca>
> Date: Wed, 11 Oct 1995 11:02:41 -0400 (EDT)
>
> 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
>
>
> Yes, but if you've just hit the SAK, you may be in a situation where the
> console is a mess, and you don't have a shell on that tty (since the SAK
> so kindly blew it away from you), so running the 'resize' program,
> assuming that you have it, may not be at all easy.....
No problem. The resize is executed automatically by init before getty.
It does have the side-effect of creating an annoying white flash every
time someone logs out of text consoles...
> 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...
>
> Well, the video drivers have to exist for SVGAlib and XF86 to use them,
> anyway. I'm just suggesting that instead of needing to implement them
> twice, once for SVGAlib and once for XF86, that we move that code into
> the kernel, where it belongs.
>
> 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).
>
> Multiuser machines where the console is publically available? I
> consider that unusual..... and generally a bad idea, since trying to
> keep a large number of machines like that secure is a real headache.
> It's generally much easier to have a few, large timesharing machines
> which are carefully administered, and then have a large number of small,
> single user machines which are publically accessinble in public
> clusters. It sounds like your university is using a very different
> model than this though.
Waterloo has had the headaches. They loaded up on Tylenol and fixed
the real problems. Assuming you installed sniffer hardware, you need
to break DES to do almost anything interesting to the machine itself;
compromising user accounts is easier when they are using unencrypted
network services but any such attack only affects the machine or the
attached network for the period of time that the sniffer is installed.
I don't know if Linux supports DES encrypted NFS, but I'm sure that
Linux isn't the first architecture not to support it, and they have the
appropriate software hanging around. Everything else already works.
There are large timesharing machines too; the workstations are primarily
used as X terminals, but CS graphics weenies don't like people sharing
their CPU and like network delays to their X terminal even less, so some
of the X terminals are in fact full-fledged Unix machines. You can even
distribute large compiles over 10 of them at a time. They are regarded as
"less available" more than "less secure"...because their power switches
aren't (yet?) encased in epoxy like they oughta be, people keep turning
them off when they appear to hang.
Most of the security threat to these machines (aside from just plain being
broken or stolen) comes from snooping and spoofing attacks on fellow students.
I've seen the occasional login prompt with just the wrong font size
more than once as a student there. Fortunately, all of the terminals
(with the exception of some Linux boxes) have some obscure way to
restart the session, ranging from line break (on serial terminals) to
combinations of keys depending on the flavor of X server
(Ctrl+Alt+CapsLock+Setup, Ctrl+Alt+Backspace, L1+A...). I figure Linux
should be at least as secure as one of these without turning it off and
on first; currently, it is not.
> 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.
>
> Do you really expect more than one user to be simultaneously using a
> console at a time? I would think it's much more likely that one user
> will be using multiple consoles, and so what you want to do is that when
> the user logs out, there is a cleanup process that remaps all of the
> keys and resets all of the console configuration to a known standard.
>
> This way, a user at your university can remap the keys to a dvorak
> configuration if he/she wishes, but when the user logs out and leaves
> the workstation, the cleanup process resets things to a standard
> configuration so that the next user to walk up to the workstation can
> get a standard configuration.
I'm not trying to help users clean up their own mess; I'm trying to
help users clean up the mess that the previous user left for them, in
as efficient and thorough a manner as possible. To do this you need at
least a way to signal that a session is to end, and you need to remove
any way to prevent this signal from reaching its target (or, in the case
of the VT_ACTIVATE call, causing the target to change. Grrr.).
