begin quoting Ralph Shumaker as of Thu, Feb 03, 2005 at 11:39:29AM -0800: > >- root access is not required to install non-core software; that is, > > software that is required to boot the system or which provides login > > capabilities requires root, and no other. > > I realize that KeyKOS has been replaced. But from what I was reading > about it, that sounds kinda like what you are wishing for here. I > recall that you chief objection to it was the persistent state. But > that aside, I think you would probably like the rest of it.
Quite possibly. It certianly *seemed* intruiging. The concept of "it's all just memory, stupid" and using disk as a sort of giant swap-space /does/ make certain programming assumptions simpler. Is it worth it? Maybe. Maybe not. I don't see the connection between files and segments, but perhaps that connection went away with hierarchial filesystems. > >- guaranteed command-sequence to provide login prompt. Even Microsoft > > got this one right with Windows NT. It would be better if keyboards > > shipped with a key that killed the current session and brought up a > > trusted login prompt. (A useful exercise is to write a program that > > emulates the linux console login, obtains a username and password, > > emits a false error and/or "simulated core dump", and then exits to > > the real console login.) > > This last bulleted item is the only one I did not follow. Did you ponder the "useful exercise"? :) Hit Control-Alt-Fn, so that you get a console login prompt. Futz around with this for awhile, then log in. Perhaps even make some notes. What does it print when you screw up? What does it print when you do it right? What does it print when you do it right but the first thing in your startup process crashes and logs you out? How hard is it to spoof that interface? It should be pretty trivial to write a program (in your favorite language, so long as console I/O is supported) that transparently emulates the login prompt, at least for sufficiently long to capture a username/password combination. Extending your program to exit with a false "error", and then exit, is likewise fairly trivial. Now, ask yourself how you can defend against this? With green-screen terminals, you would restart the terminal. Likewise with Linux -- power-off, power-on -- however, this is time-consuming, annoying, impractical, and likely to cause problems on your Linux box. Ought not the operating system provide you with a way to always get a known-good-to-you login-prompt? Some way that user-code cannot intercept, detect, or redirect? (Answer: yes.) Microsoft, for all their faults, *listened* to those who pointed out that this was a risk, and repurposed control-alt-delete to fulfill the task of bringing forth a known-good component of the operating system. Actually, I suspect the Windows NT guys, but I don't actually recall. (They didn't lock down the rest of the operating system that well, but that's a different matter.) So, other than power-cycling my machine, I ought to have a way that I can bring up a known-good login prompt (console or XDM) that no user-space code can intercept. Ideally, we'd have a "login" key on the keyboard that would be intercepted by the operating system and never *seen* by user-code. [No need to quote signatures] -Stewart "Been a long time since I last wrote a login-emulator" Stremler -- KPLUG-List mailing list [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
