[398] in linux-security and linux-alert archive
Re: console security (was Re: problem wi
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Thu Sep 28 17:06:19 1995
Date: Thu, 28 Sep 1995 13:58:51 -0400
From: "Theodore Ts'o" <tytso@MIT.EDU>
To: "Miller, Raul D." <RDMiller@legislate.com>
Cc: kjh@seas.smu.edu, owner-linux-security@tarsier.cv.nrao.edu,
linux-security@tarsier.cv.nrao.edu
In-Reply-To: RDMiller@legislate.com's message of Mon, 25 Sep 95 23:35:00 PDT,
<30679F56@smtpgw.legislate.com>
From: "Miller, Raul D." <RDMiller@legislate.com>
Date: Mon, 25 Sep 95 23:35:00 PDT
I don't know if it works, but last time I checked the copyright on
setserial prevented its free distribution. Personally, I don't think
of a feature as belonging to linux if the code to enable that feature
can't be distributed in the same manner as the kernel.
Huh? There is no copyright notice on setserial at all, mostly because I
never got around to it --- it was originally such a trivial program that
I never bothered. An oversight on my part; the intent was that the file
be freely redistributable, and indeed it's my impression that most
distributions are including it as a matter of course.
This is the first that I had heard that anyone had any hangups about the
copyright status of setserial; I wish people who had such concerns would
contact me directly, instead of flaming publically about it. I very
easily put a free redistribution notice on the file, if that what it
takes to make people happy.
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.
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.
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
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
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).
- Ted
