[421] in linux-security and linux-alert archive
Re: console security (was Re: problem wi
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Sat Oct 14 11:04:51 1995
Date: Fri, 13 Oct 1995 14:52:23 -0400
From: "Theodore Ts'o" <tytso@MIT.EDU>
To: Zygo Blaxell <zblaxell@calum.csclub.uwaterloo.ca>
Cc: RDMiller@legislate.com, kjh@seas.smu.edu,
owner-linux-security@tarsier.cv.nrao.edu,
linux-security@tarsier.cv.nrao.edu
In-Reply-To: Zygo Blaxell's message of Wed, 11 Oct 1995 11:02:41 -0400 (EDT),
<199510111502.LAA03411@calum.csclub.uwaterloo.ca>
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.....
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.
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.
- Ted
